Off-the-shelf or custom software?
If the process is the reason you make money, build it. If it is everybody’s process (accounting, payroll, order to cash), buy it: a market product has thousands of installations that have already tested it. Most companies end up doing both, keeping the ERP and building only the part it does not cover.
The question is usually badly framed, because the answer does not depend on the software: it depends on which part of your work you are digitising.
The rule, in one line
If the process is the reason you make money, build it. If it is everybody’s process, buy it.
The rest of this article is what to do when that line is not enough.
When buying is the right answer
We are writing this as people who sell custom software, because it is the part nobody tells you at the first meeting.
Buy a market product when the process is standard: accounting, order to cash, payroll, expenses. There is no way to beat a product with thousands of installations: it has already met the strange cases on your behalf, and every regulatory update arrives without you asking.
Buy also when the process is not yet stable. Digitising something you are still deciding how to do means writing a temporary decision into code.
And buy when the custom alternative would leave you with nobody able to maintain it.
When the standard product stops holding
The signal is not a missing feature. It is the spreadsheets around the ERP.
When you find a shared file in a department that holds the real status, a sheet of paper taped to a machine, or a person who reconciles two systems by hand every Monday, the standard product has already stopped holding: somebody is paying the difference with their own time, every week, and it appears in no budget.
The other signal is when the ERP vendor tells you that cannot be done, and you change the process to suit them. If the process you are changing is the one you make money on, you are giving up an advantage to avoid rewriting a piece of software.
What actually differs
Not the feature list. Three things:
Who adapts to whom. A standard product asks you to work the way it works. Custom is the other way round. On ordinary processes adapting is cheaper; on the ones where you differ from competitors it is exactly what you must not do.
Who decides what changes. A product evolves on its vendor’s plan, which accounts for ten thousand customers and not for your plant. Custom software changes when you decide.
Who owns the code. With custom, source and documentation belong to whoever paid. It is also why security can be tuned to your data instead of to a market average, and for anyone handling health data or process formulas that is not a detail.
The third road, which in practice is the common one
Almost nobody really chooses between the two. You keep the ERP for what it does well and build custom only for the part it does not cover, connecting the two.
It costs less and lasts longer: nobody rewrites accounting that works. The difficulty moves entirely to the integration (reading from and writing to the ERP even when it is old, without upgrading it) and that is the work we do most often.
Price and cost are not the same thing
A standard product has a low entry price and a cost that continues: licences per user, extra modules, maintenance fees, and every customisation billed separately by the vendor, who is the only one who can do it.
Custom software is the opposite: a higher initial investment and no licence to renew in order to keep using what you paid for.
Which one wins depends on how many years it stays in service and how many people use it. Over five years and fifty users the arithmetic often changes sign compared with year one, and that is the arithmetic to do first, not a comparison of two entry prices.
What to ask your ERP vendor first
Before writing anything from scratch, three questions for whoever sold you the system. The answers change the decision:
- Is there already a way to do this, even an awkward one? Sometimes the feature exists and is switched off, or is called something else.
- What would it cost and when would it arrive if you built it? A quote from your current vendor is the most honest benchmark you have.
- Does the system expose its data to another application? If yes, the third road is easy; if no, that is the first problem to solve and it belongs in the budget.
The mistakes we see most often
Buying custom for a standard process. More expensive and worse than a product tested by thousands of installations.
Bending the process to the product even where you make money. The easy choice in the short run and the expensive one later: you give up the difference that makes customers choose you.
Building custom without integrating. An application that does not talk to the ERP creates a second set of records to reconcile by hand.
Deciding in a meeting room. The question “does the standard product cover the process?” has one answer on the shop floor and another in the procedures. The shop floor one is the true one.
How to decide, in practice
Take the process and ask two things: does a competitor do it the way we do? and if we did it better, would it show in the numbers?
Two yeses and a no already tell you where you stand. If you cannot answer, the answer is found by watching the department for half a day, which is exactly how we start, before any quote.
Tell us about the process, or read when custom software is worth it.