Manufacturing software fails on connectivity, machine data, and shift reality rather than on features. Here is what actually drives a custom build on the floor.
Codestreaks Team
Manufacturing software development means building production, inventory, quality, and maintenance tools that run in a place where the network drops, the hardware is older than the company's website, and the person using it is wearing gloves. The code is rarely the hard part. The environment is.
We have delivered 30+ projects to production since 2024, and the manufacturing work has a consistent tell. Requirements gathered in an office describe a process nobody on the floor actually follows. Then you go stand next to the line for a day and find the real one, which involves a clipboard, a whiteboard, and one person who remembers everything.
Here is what actually decides whether a custom manufacturing build lands.
WiFi on a shop floor is worse than anyone in the office believes. Metal, machinery, and distance conspire against it, and the dead zone is usually exactly where the work happens.
So a floor application has to keep working with no connection and reconcile later. That single requirement changes the architecture completely. You need local storage, a queue of pending actions, conflict handling for the case where two tablets recorded the same job from different sides, and a UI that tells the operator plainly whether what they just did is saved or waiting.
Teams that treat offline as a nice-to-have ship an app that works in the demo room and gets abandoned in week two, because the operator learned it loses data. You get one shot at that trust. We scope offline behavior before screens, the same way we scope integrations first in our general custom software development process.
Everyone wants machine data on a dashboard. Then you look at the machines. A newer CNC might speak MTConnect or OPC UA. An older press has a PLC with a serial port and a proprietary protocol. A third has nothing at all, and the only real signal is a light on top.
What that means practically: getting data off the floor is an integration project per machine class, and sometimes a hardware project. A current sensor on a power line will tell you whether a machine is running when nothing else will, and it is often the fastest honest answer to utilization questions.
Budget the survey. Walk the floor, list every machine, note make, model, controller, and whether it has a network port that IT will actually allow on the network. That list drives the estimate far more than the dashboards do.
Most manufacturers already run an ERP, and it holds the parts, the orders, and the truth about inventory. Your new tool does not replace it. It has to live beside it without creating a second version of reality.
The rule we apply: one system owns each fact. If the ERP owns inventory, your app never writes an inventory number it invented, it writes a transaction the ERP applies. The moment two systems both believe they own stock levels, somebody spends every Friday reconciling them by hand.
This is where the 2am pattern shows up in manufacturing. Ops staff doing triage by hand at night because the tool does not talk to the other tool, exporting a spreadsheet from one system to import into another. That gap is usually one integration away from gone, and it is the kind of unglamorous automation that pays back fastest. Most teams do not need a transformation program, they need three boring workflows automated well.
Interface work on the floor is not aesthetic work. Touch targets have to survive gloves. Contrast has to survive overhead lighting and grime on the screen. Alerts have to be visible in noise, which usually means visual, not audio.
And every extra tap costs real money. If a data entry step takes 20 seconds and happens 400 times a shift, that is over two hours a day, and the floor will route around it. Operators are not the obstacle. They are the fastest quality signal you have. If they abandon the tool, the tool is wrong.
The most useful hour we spend on any manufacturing project is the one standing at the station watching someone do the job without being interrupted.
Useful now: visual inspection for defects with a narrow, well-labeled scope, anomaly detection on sensor streams, maintenance scheduling from machine history, and pulling structure out of the free-text notes maintenance techs have been typing for years.
Not useful now: anything that decides to stop or start production on its own. That is a safety-adjacent path and it belongs behind deterministic logic with a human in the loop.
The economics are usually fine. Production agents typically run $50 to $2,000 per month, and good engineering around caching, model routing, and prompt design cuts that by 3 to 10 times. The blocker is rarely cost. It is that an agent without an evaluation suite is a liability with a chat interface, and on a factory floor the cost of a confident wrong answer is measured in scrapped parts.
Our typical engagement runs 4 to 8 weeks from kickoff to live deployment, at $8,000 to $60,000 fixed price. For manufacturing specifically:
A single-purpose floor tool, such as a digital job traveler or a quality check replacing paper, sits at the low end and ships inside the normal window. We built the Rope Access Logbook, a digital logbook replacing paper in an industrial safety context, in 8 weeks, and that shape of project is the most reliable win available in a plant.
A connected system spanning several machine classes, an ERP integration, and floor tablets is a phased build at the upper end, because each machine class is its own integration. Anyone quoting that without having walked your floor is quoting screens.
The highest-return first project in almost every plant is the paper form that everyone hates. It is bounded, its value is obvious the first week, and it earns you the credibility to do the harder connected work later.
Buying a platform first inverts that. You spend months configuring something general before anyone on the floor gets a single day better, and the project becomes an IT initiative rather than a floor improvement. We would rather ship the boring thing in six weeks and let the floor ask for the next one, which is also the argument in our writeup on what is process automation.
The environment sets the constraints. Offline operation, machine protocols, gloves and lighting, and an existing ERP that owns the data all shape the architecture before any feature does. The web stack itself is usually ordinary.
Buy when your process matches what the product assumes and you can adapt to it. Build when your advantage lives in a process the standard product cannot express. Many plants end up with an MES for the standard flow and a small custom layer for the part that is genuinely theirs.
Three options in increasing cost: a gateway that speaks the machine's existing protocol, retrofit sensors that measure something physical such as current draw, or operator entry on a tablet. Sensors are often the honest fastest answer for utilization questions.
A single bounded tool, such as replacing one paper form, typically ships in our 4 to 8 week window and can be piloted on one line before it goes plant-wide.
Someone who works on or near the floor, not only IT. The projects that stall are the ones where nobody with production authority is accountable for adoption.
If you are considering a build, the useful first conversation is about one workflow and one line, not a platform. We offer a free 30-minute scoping call and reply within two business days. We take two engagements per quarter, and we say no when the scope does not fit.
See how we approach custom web development, or start a project and tell us which form on your floor is still paper.
