Walk into almost any small plant and you will find the same arrangement: an ERP that finance trusts, a machine or two with proprietary software of their own, a CMMS somebody bought three years ago, and — holding the whole thing together — a spreadsheet on a shared drive that one person maintains and everybody depends on.
Nobody planned that. It accumulated. And it works, right up until the person who owns the spreadsheet takes two weeks off, or a customer asks for traceability the system cannot produce, or you try to calculate OEE and find the numbers live in four places that disagree.
The takeaway up front: the choice is rarely "buy software" versus "build software." It is a choice between configuring what you already own, integrating the systems you already run, and building the one piece nothing off the shelf covers. Plants that jump straight to a big purchase, or straight to a bespoke build, usually pay for the wrong one.
First, separate the three options properly
They get discussed as points on a single line from cheap to expensive. They are not. They solve different problems.
Configure what you have. The cheapest genuine option, and the most commonly skipped. Plenty of plants run 30% of a system they already paid for. Before anything else, find out what your existing ERP or MES module does when it is set up properly, and what it would cost to have someone configure it that way.
Integrate what you own. Often the problem is not a missing system but three systems that cannot talk. Machine data sits in one place, work orders in another, and a human retypes between them. Integration work — an API, a shared database, a scheduled sync — is a fraction of the cost of a new platform and removes the specific failure that hurts: manual re-entry.
Build what nothing covers. Custom software earns its keep where the process is genuinely unusual, where the workflow is the competitive advantage, or where the off-the-shelf option would need so much bending that you are paying licence fees for a product you have effectively rewritten.
Worth saying plainly: build is the right answer less often than software vendors imply, and more often than owners fear. It is a decision, not a personality trait.
The four questions that actually decide it
1. Is this process standard, or is it yours?
Payroll is standard. Preventive-maintenance scheduling is standard — there are mature products for it, and our guide to choosing a CMMS covers that market. But the way you schedule a mixed-model line around one shared bottleneck, or the inspection routine a specific customer contractually requires, may be genuinely yours. Standard processes should buy. Distinctive processes are where custom pays.
2. What is the workaround costing you now?
Put a number on the spreadsheet. Hours of re-entry per week, scrap caused by working from a stale version, the day lost to month-end reconciliation, the risk concentrated in one person's head. That number is both your budget ceiling and your payback clock. If nobody can produce it, the project is not ready — you would be buying software to fix a problem you have not measured.
3. Who owns the data, and can you get it out?
This one gets skipped and then hurts for years. Ask any supplier — product or custom — where the data physically lives, whether you can export all of it in a usable format, and what happens to your access if the relationship ends. A system you cannot export from is a system you can never replace.
4. Who runs it in month seven?
Software does not end at go-live. Somebody patches it, somebody adds the field the new customer wants, somebody restores the backup nobody has tested. Decide at the start whether that is your team, the vendor, or a named support arrangement — and get it in writing. The same discipline applies here as on the shop floor: digitising a process only sticks when ownership is assigned, which is the argument our framework on whether to automate a manufacturing process makes about equipment.
Do not digitise a broken process
The most expensive mistake is taking a messy manual routine and reproducing it faithfully in software. You get the same waste, now with a licence fee and a change-request form in front of it.
Map the process first. Strip the steps that exist only because of how the paper used to move. Then decide what to configure, integrate or build. It is the same ordering that governs automation — simplify, then mechanise — and it is what separates a system people use from one that gets quietly worked around within a quarter.
Where a development partner fits
If the answer lands on "integrate" or "build," you are buying engineering rather than a product, and the supplier's process matters more than their technology stack.
Softnika Solutions is one firm worth looking at for a reason specific to this decision: instead of selling a single platform, it publishes its consultancy as six named practices — digital transformation, enterprise mobility, cloud consultancy, business process automation, big data consultancy and IT infrastructure consultancy — and describes business process automation as targeting the event-based, mission-crucial and core processes rather than routine data handling. Its digital transformation work is framed as identifying the gaps between where an organisation is now and where it is required to be. That is the right sequence for a factory: name the gap, then decide what gets built. Enterprise resource planning systems and web and mobile application development sit alongside it, so one supplier can scope both the integration and the interface an operator actually uses at the line.
Whoever you talk to, the test is the same. A supplier who asks what the process looks like before quoting is doing the job. A supplier who quotes from a feature list is pricing a guess.
Make the quotes comparable
Two development quotes almost never describe the same job, which is why they are so hard to read side by side. Before you send a brief, settle four things and put them in it:
- What the software replaces — the spreadsheet, the re-entry step, or a licence you currently pay for.
- Who the users are. Office staff on a desktop and operators on a tablet at the line are two different builds.
- Which systems it must talk to, and who owns each of those integrations.
- Who operates it after launch, and what a change request costs.
Give every supplier that same page. The quotes become comparable — and the ones that will not engage with it have told you something useful.
FAQ
Is custom software risky for a small manufacturer?
It carries real risks — overrun, key-person dependency, and being tied to one supplier — and they are managed rather than eliminated. Scope one process, not the whole plant. Insist on data export in writing. Agree who maintains it before you sign. A first phase small enough to fail cheaply is the best protection available.
Can we start with a spreadsheet and migrate later?
Yes, and often you should. A spreadsheet that models the process correctly is an excellent specification for whatever replaces it. The problem is not the spreadsheet; it is the spreadsheet still running production three years later with no owner and no backup.
How long should a build take?
Ask for a stated range rather than a promise. A supplier who commits to a window has scoped the work; one who says "as soon as possible" has priced it without scoping it. For a single process, think in weeks to a few months — if the first answer is a year, the scope is too big for a first phase.
Should the same supplier do the integration and the app?
Not necessarily, but there is a practical argument for it: when a data sync breaks between two suppliers, you own the argument. One accountable party for the pieces that touch each other usually saves more time than it costs.
Next step
Before you approve a purchase or a build, write down the three decisions the software has to support — the ones somebody makes today from that spreadsheet — and who makes them. That list, not a feature grid, tells you whether to configure, integrate or build.
If it points at engineering rather than a product, take the same page to Softnika Solutions or any other development firm and ask them to respond to the process rather than the wish list. The reply tells you most of what you need to know about a supplier before any money moves.
