Custom Software and Business Applications in Kocaeli

Where the spreadsheet stops being enough

A large share of the production companies in this province run stock, planning and dispatch on spreadsheets, and we are not going to pretend that is absurd. Up to a certain size it genuinely works, it costs nothing, and the person who built the file usually understands the business better than any outside consultant would.

The trouble starts when the company outgrows it. Three copies of the same file start circulating, nobody can say who changed which row, and a broken formula is noticed weeks after it began producing wrong numbers. What passes between shifts stays verbal. Then comes the risk nobody plans for: the person who built the file leaves, and no one left in the building fully understands the system.

For exporters there is a second pressure that arrives from outside. A customer running a supplier audit asks which batch a part came from, which check it passed and who signed it off. Producing that answer from a spreadsheet is possible. Defending it in front of an auditor is a different exercise entirely.

A package, or something built for you

We ask this before quoting anything, because the honest answer is often that you do not need custom software at all.

If your process is ordinary, meaning standard goods in and out, standard invoicing, standard account tracking, then an existing package will solve it faster and for less money. We say so rather than selling development hours against a problem that is already solved.

Purpose-built software earns its cost when your process diverges from the sector norm and that divergence is the thing you compete on. Cutting to order, offcut and yield calculation, batch-level traceability, a pricing rule nobody else uses, an assembly sequence no package models. A sheet metal slitting operation calculates waste in a way that has almost nothing in common with how a textile plant plans cutting; a general package covers both roughly and neither properly.

The question that usually settles it is simple. To fit the package, would you have to change how you actually work? If the answer is yes, that is the moment to stop and think.

How a software project runs

The first step is seeing the floor. Who runs the process, where they write things down, and where mistakes actually surface are not things you learn in a meeting room. Within Kocaeli we come and look.

Then the scope goes into writing. The largest risk in software work is scope growing quietly during production until neither side recognises the original agreement. We manage that by defining it up front and pricing changes separately as they come.

Development is delivered in pieces. The most critical module goes live first, you start using it with real data, and the rest follows what you learn. Working for months and then presenting one large delivery is the most expensive way to discover a misunderstanding.

Commissioning includes user training and data migration. Where the data in your old spreadsheets is in usable condition, it moves into the new system rather than being retyped.

What makes it survive on the shop floor

Software that lives in a production environment has constraints an office application never faces, and systems written without them simply do not get used.

The screen has to work for someone wearing gloves in a dusty place. Small buttons, long forms and deep menus fail there. Whatever the operator does twenty times a shift has to finish on one screen in a few taps.

Barcodes and labels need planning at the start, not at the end. Which printer, what label size, what the code carries: these are the backbone of the system rather than details to be added later.

Permission levels have to mirror the real hierarchy. A shift supervisor and an operator should not see the same thing, but permissions must not be so tight that people start borrowing each other's accounts to get the job done. That balance cannot be designed from a distance, which is why we ask to visit before writing anything.