Manufacturing software development services, built around your floor

Why does the ERP not already solve this?

Because ERP planning runs on standard values rather than what the floor is actually doing. Research from EPFL on shop floor integration puts it directly: ERP planning is mostly based on theoretical values, averages, and not on actual real shop floor data, which disrupts the planning algorithms it feeds.

That single sentence, from EPFL research on ERP and shop floor data, explains most of what follows on this page. An ERP is a system of record, and it is good at that. It holds the bill of materials, the order, the cost. What it does not hold is the state of the line five minutes ago.

The gap shows up most clearly in scheduling. Standard ERP capacity planning works on routings and averages, and it does not model setup time that changes with sequence, tooling that is shared between cells, or the fact that only three operators are signed off on a particular machine. One analysis of ERP capacity planning describes the consequence precisely: planners fall back to spreadsheets to model what the system cannot, and those spreadsheets become, in its phrase, an unmanaged simulation engine running the plant.

So the real schedule leaves the ERP and moves into a file on someone's desktop. Nobody decided this. It happened because the tool did not fit the job, and a competent planner did what competent people do.

What is the spreadsheet nobody admits to?

The parallel system. Almost every plant has one: a scheduling file, a stock sheet, a quality log kept outside the ERP because the ERP version does not work. An ERP vendor guide describes these parallel spreadsheets as a form of passive resistance that undermines data accuracy, which is a fair description of the effect and an unfair one of the cause.

The cause is usually that someone was asked to do a job with a tool that does not fit it, and found a way. The spreadsheet is evidence of competence, not of sabotage. Treating it as resistance is how improvement programmes lose the people who understand the operation best.

What the parallel system costs you is specific and worth naming. The real plan is not visible to anyone outside the person who maintains it. Nothing in it is audited. It does not survive that person leaving, or being ill during a busy week. And because the official system is known to be wrong, every number it produces gets quietly discounted by everyone who reads it, including the ones that are correct.

The right first question is not how to stop people using spreadsheets. It is what the spreadsheet does that the system cannot, because that answer is the requirement document for the software you actually need.

What are the signs there is a real project here?

Eight symptoms, and most plants we speak to have four or five of them. If more than two are true, there is almost certainly work worth doing, and it is usually smaller and cheaper than the ERP replacement somebody has proposed.

Trade press on machine shop systems lists the same tells from a different angle: multiple versions of the same production file, schedules that are out of date, duplicate data entry, and inventory counts drifting because consumption is not recorded as it happens. Different language, same plant.

Where does the money actually leak?

Downtime you cannot attribute, expediting that nobody budgets for, and the labour spent moving numbers between systems. Downtime is the one with published figures: Siemens put unplanned equipment downtime at roughly 1.4 trillion dollars a year across Fortune Global 500 companies in its 2024 report, around 11 percent of revenue, up from about 8 percent in 2019 and 2020.

Those headline numbers belong to very large companies, and per hour figures vary enormously by sector. Siemens is cited at roughly 2.3 million dollars an hour for automotive and around 36,000 for fast moving consumer goods. A commonly quoted general manufacturing average of about 260,000 dollars an hour traces back to Aberdeen research rather than Siemens, and secondary sources repeat it loosely. For a small job shop, one analysis suggests something closer to 5,000 dollars an hour.

We quote the range rather than a single figure because the single figure is almost always wrong for your plant, and because most of these numbers reach you through vendor blogs that cite the underlying studies casually. The useful exercise is not adopting someone else's number. It is working out your own: contribution per hour on the constrained line, multiplied by hours lost, which you can only do once downtime is measured with a reason attached.

That is the argument for downtime capture, and it is a small build. It is usually the first thing we do in a plant, because it produces a number that makes every later decision easier to justify.

Why do so many ERP and plant software projects fail?

The published evidence disagrees, which is itself worth knowing. One consultancy figure widely repeated in 2026 puts discrete manufacturing ERP failure at 73 percent with cost overruns reaching 215 percent, but it circulates through vendor pages rather than the original report. An older independent survey of over 300 North American manufacturers and distributors found roughly two thirds rating their implementations successful.

Treat both with suspicion. The alarming figure is marketed by firms selling rescue services. The reassuring one is eight years old and asked companies to grade their own projects.

The more useful finding comes from an analysis of 70 small manufacturer implementations, which concluded that the primary barriers were data preparation and organisational readiness rather than software complexity, with only a small minority citing integration problems. That matches what we see. Projects do not usually fail because the technology was too hard. They fail because the part number data was a mess, because nobody decided who owns the definition of a finished good, or because the plant was asked to change how it works during its busiest quarter. The same analysis found a median implementation time of about two months for small manufacturers, though it drew on customers who agreed to be case studies, which will skew it optimistic.

What that means for scoping: spend the first week on the data and the decision rights, not the screens. If nobody can tell you which of two SKU definitions is correct, that is the project, and software built on top of the ambiguity will simply distribute it faster.

How do CRM and quoting fit into this?

Badly, in most plants, because sales quotes without seeing production. The recurring failure described across quoting and configuration vendors is that reps configure and promise without the technical knowledge of manufacturing constraints, and the result is costly adjustments, delays and a customer who was told something untrue.

The mechanics are usually the same. A quote is built in the CRM or a spreadsheet. The date comes from an assumption about lead time rather than current load. The order is then re-entered into the ERP, which is both a transcription risk and a second chance for the two systems to disagree about price. Vendors in this space describe the same pattern: quotes that do not talk to the ERP or CRM cause double entry, order errors and missed handoffs.

You do not need a full configure price quote platform to fix the common cases. Three smaller things cover most of it.

Give sales a load view. Read only, current, honest. A rep who can see that the line is committed for three weeks will quote four, and will stop being the person who causes expediting.

Stop the re-entry. Won quote becomes an order in the ERP without anyone retyping it. This is an integration, usually a small one, and it removes an entire category of error.

Put the margin rule in the system. Approval thresholds enforced where the quote is built, rather than discovered at month end.

Our systems integration pages cover the mechanics for specific platforms, including what to do when the ERP has no usable API.

What about traceability and compliance?

Traceability only works if the links are captured during production. Reconstructing them afterwards is what makes recalls expensive and audits painful. For food businesses specifically, the FDA's Food Traceability Rule under FSMA section 204 requires detailed electronic records of critical tracking events, with records produced to the FDA within 24 hours of a request.

One thing worth getting right about the timing, because it has changed and plenty of advice online is now out of date. The compliance date was pushed to 20 July 2028, after Congress directed the FDA not to enforce before then in the Continuing Appropriations Act of 2026. The rule itself did not change, only the enforcement date.

That is not a reason to stop. Industry bodies have pointed out that the largest retailers are holding their suppliers to the original timelines regardless of what the FDA enforces, so for many processors the real deadline is commercial rather than regulatory. If your customer is a national grocer, their schedule is the one that matters.

Practically, traceability is a capture problem rather than a reporting problem. If lot links are recorded as material moves, a trace is a query that returns in seconds. If they are not, no reporting layer can invent them, and you are back to a week with paper records. We cover this in more depth for agriculture and food processing.

What happens when the people who know things retire?

The rules leave with them. Deloitte and the Manufacturing Institute have projected around 2.1 million US manufacturing jobs going unfilled by 2030, with an earlier study in the series putting more than 2.7 million workers leaving through retirement over a decade. The number that matters to a single plant is smaller and more specific: how many people hold a rule nobody wrote down.

Every plant has them. The setter who knows this tool runs hot on Mondays. The planner who knows that customer always calls off early. The quality manager who knows which supplier's material needs the extra check. None of it is in the ERP and none of it is in a procedure.

Software does not capture tribal knowledge by existing. It captures it when the system asks for the reason alongside the action: why this was scrapped, why this job was resequenced, why this batch was held. Collect reasons for a year and you have a dataset that encodes what the experienced people know, in a form the next person can use.

That is a design decision made at the start, and it costs almost nothing. Added later it is a migration, because the historical records do not have the field.

What do you actually build for manufacturers?

Eight things, in rough order of how often they pay back fastest. Most plants start with one of the first three, because they produce a measurable number within a month and that number funds the rest of the programme.

None of this replaces your ERP. All of it writes back to it. That is a deliberate position: ERP replacement is a multi year project with a contested success rate, and the operational pain you feel today usually sits in the layer above it.

How do you connect to an ERP that has no API?

With whatever it does have. Plenty of regional and older manufacturing ERPs expose no public API, and that changes the design rather than stopping the project: a read only database view, a scheduled export, a file drop the system already produces, or in the worst case a middle table both sides can see.

This is the question that decides the shape and cost of a plant integration, so we establish it in the first few days, before quoting. The answer is rarely what the vendor's website implies.

What we look for, in order of preference. A documented REST or SOAP interface, which makes everything straightforward. Failing that, read only access to the database, which is often available and often not advertised. Failing that, a scheduled export, which is fine for anything that does not need to be live. And if none of those exist, an intermediate table that the ERP can write to and read from, which is inelegant and works.

The specific platforms are covered on our integration pages, including ERP systems generally, SAP and NetSuite. The honest summary for any of them: access is usually the long pole, not the code, and the time is spent getting the right service exposed rather than writing against it.

What about machines that produce no data at all?

Most plants have them, and they do not stop the project. Older equipment falls into three groups: machines with a serial or network interface that nobody has ever connected, machines that produce a file or a printout, and machines that genuinely output nothing. Each has a different and known answer.

Establishing which group each machine falls into is the first technical question we answer, because it changes the cost more than anything else in the scope.

Machines with an interface nobody uses. Far more common than people expect. A serial port, an OPC server, a network card installed at commissioning and never configured. Reading these is straightforward once someone has the manual and access to the controls cabinet.

Machines that produce a file or a print. A shift report, a quality printout, a CSV on a USB stick. Unglamorous, and perfectly workable. We have built capture around a file drop more than once and the data is no less useful for arriving every hour instead of every second.

Machines that output nothing. Here the honest answer is a fast manual capture at the line: a tablet with large buttons, three taps, under ten seconds. Operators will do that reliably. They will not fill in a twelve field form, and any design that assumes they will is going to fail quietly.

There is a fourth category worth naming because it causes arguments: machines that could be instrumented with a sensor retrofit. That is real engineering with a real budget, and we would not propose it in a first project. Start with the machines that already talk, prove the value, then make the case for the sensors with evidence rather than a proposal.

One caution on the modern version of this problem. A connected machine on a plant network is an attack surface, and plant networks are frequently flat. We do not do industrial control security, and we will say so, but we will flag it rather than quietly putting a new device on the same network as your production control. If that needs looking at properly, it needs a specialist.

How do you know whether the software worked?

Pick two numbers before the build and measure them after. The useful ones are specific: hours of downtime attributed to a reason code, time between the event on the line and the number being visible, and the share of shifts where the entry was completed without a chase. Not adoption percentages.

Most plant software is judged on whether people like it, which is a poor measure in both directions. Here is what we agree to measure in week one.

Latency from event to visibility. Before, this is usually the next morning. After, it should be seconds. This single number captures most of the value, because everything downstream depends on acting while the shift is still running.

Share of downtime with a cause attached. Not total downtime, which moves for many reasons. The share you can explain. Going from a third to nine tenths is what turns downtime from a topic into a plan.

Completion without chasing. If a supervisor has to ask people to fill it in, the design is wrong and the data will degrade the moment attention moves elsewhere. We treat chasing as a defect, not a training issue.

Time to answer a traceability question. Ask the same question before and after: which batches used this lot. A week against a few seconds is a number any auditor or customer understands immediately.

Review these at thirty days and ninety. The thirty day review is about the design and whether the floor accepted it. The ninety day review is about whether to roll out to the next line, and it is a much easier conversation when the numbers were agreed in advance rather than argued about afterwards.

When should you not build custom manufacturing software?

When the ERP already does it and nobody configured it, when the real dispute is between two departments, when nobody will own the system after launch, or when what you need is a report rather than a system. We check all four before quoting, and we lose work by doing so.

The pattern underneath all four is the same: a plant feels operational pain, assumes the answer is new software, and nobody checks the cheaper options first. Checking takes a week. Not checking costs a quarter.

How does a project start, and how long does it take?

One line or one plant, four to six weeks, with something the operators use in production at the end of it. We do not start with a plant wide rollout, because the first version is always wrong in ways only the floor can tell you, and it is far cheaper to be wrong on one line.

1. 01

   Walk the floor

   Days 1 to 3

   We watch the process, read the spreadsheet that runs it, and find out what the ERP can already do. This is where most of the scope gets decided, and it is where we tell you if there is no project.

2. 02

   Fixed scope and a date

   Week 1

   A line by line quote, an agreed first deliverable, and a written list of what is explicitly not included.

3. 03

   Build on one line

   Weeks 2 to 5

   Working software in front of operators in week three, not week six. Their first reaction changes the design, which is the point of starting small.

4. 04

   Measure, then roll out

   Week 6 onward

   If it has not made that line easier to run, there is nothing to roll out and you have risked four weeks. If it has, the next line follows the same pattern.

Two things decide whether operators adopt it, and neither is technical. It has to be faster than the paper it replaces, which means a handful of large targets, no passwords to type and no waiting on the network. And the person who runs the line has to have been involved in designing it. Systems designed in the office and delivered to the floor get worked around, and then you have two parallel systems instead of one.

Who in the plant needs to be involved?

Four people, and only one of them is from IT. The operator or setter who will use it every shift, the supervisor who owns the line, one person with authority to settle a definition, and whoever administers the ERP. Projects that skip the first are the ones that get worked around.

The operator or setter. They decide whether this succeeds, and they will tell you in ten minutes what is wrong with a design that took a week to draw. We want them in front of a working screen in week three, not shown a finished system in week six.

The line supervisor. They know which exceptions are routine and which are genuinely rare, which is the distinction that keeps a system from drowning in edge cases nobody encounters.

Someone who can settle a definition. When two sites count a SKU differently, somebody has to decide which is correct, and they need the authority to make it stick. This is the role most often missing, and the project stalls without it regardless of how the software is built.

The ERP administrator or the vendor's support contact. Access is usually the long pole on any integration. Starting that conversation in week one rather than week four routinely saves a fortnight.

What we do not need is a steering committee. If four people with those roles can give an answer within a day, a plant project moves at a reasonable pace. If every decision waits for a monthly meeting, no amount of engineering will make the timeline work, and we would rather say that at the start.

What do manufacturing software development services cost?

Scope decides it and we quote line by line after walking the floor, never before. A first project on one line is typically four to six weeks. We run two rates: a blended squad at roughly 24 to 45 dollars an hour, and a senior only pod at roughly 75 to 120 where architecture or a compressed timeline decides the outcome.

Worth planning for beyond the build: hosting, which for this kind of system is usually small, and maintenance at roughly 15 to 20 percent of the build each year to cover dependency upkeep and the changes your ERP vendor imposes on you. Those figures are our own planning assumption rather than an industry standard, and we would rather state them than leave them out of your budget.

Indicative until we have scoped the work. We are a small remote team working US business hours with engineering based in Pakistan, which we put on the page rather than in a footnote. You can read about the team, including what we have built for ourselves.

• Manufacturing marketingGetting specified, and proving which enquiries became orders
• Custom software for manufacturingLine side tools and operations systems
• AI and automationRemoving hours, not adding novelty
• Dedicated development teamsEngineers who learn your process and stay
• ERP integrationIncluding systems with no public API
• Food and agri processingTraceability, quality capture, yield
• Logistics and fleetsDispatch, proof of delivery, tracking