Off-the-Shelf Software or a Custom Build? A Decision Guide for Business Owners
Sooner or later the same question lands on the owner’s desk: “Do we buy a package, or have something built for us?”
It usually arrives with a squeeze behind it. Production planning has outgrown the spreadsheet, the field crew is taking jobs over WhatsApp, or the current system no longer fits the company you’ve become. Two quotes come in, one is three times the other, and both sides present beautifully.
This is written for the person sitting at that table. I won’t give numbers — they move too much with sector, scope and currency. But there is a way to decide based on the shape of your own business rather than on who presented better.
The question is framed wrong
“Which is better?” has no answer, because each is better at something. The right question is:
Is this process where we differ from our competitors — or is it the thing everyone in the industry does much the same way?
That single question settles roughly 80% of the decision.
Where everyone works the same way, you buy. Payroll, invoicing, accounting, general stock movement. Being “bespoke” in these processes isn’t an advantage, it’s an expense. When a dozen vendors have spent years polishing a product, commissioning the same thing from scratch also puts every future regulatory change on your own back.
Where your difference lives, you build. The way you keep the promise you made to a customer, the logic behind your production schedule, how the field crew picks up work. Buying a package here means bending the process to fit the software — and if that process is what separates you from competitors, the moment you bend it you have erased the difference.
The trouble is that most businesses ask for quotes without ever making this distinction. The process is never described, so the quotes can’t be compared — each one prices something different.
The hidden cost of buying
A package’s price is visible; its cost is not. Four items arrive after the quote:
- Adaptation. Bending your processes to the software. This is not a training matter, it’s a change in how work is done, and it is paid for in lost productivity over the first six months.
- Data migration. Moving what lives in the old system, in spreadsheets and in people’s heads. Usually not in the quote, usually twice as long as estimated.
- Annual increases. The licence is attractive in year one and a different number in year three. Check whether the contract caps the increase.
- Exit cost. If you don’t like it, in what format and how quickly can you get your data out? A question with no answer is a quiet dependency.
These items settle into overhead by seeping in. I wrote about how that seepage works in the subscriptions that renew quietly.
The hidden cost of building
With custom software people talk about the build price. The real item is keeping it alive: bug fixes, operating-system and device updates, regulatory changes, new needs.
A practical rule: the build price is not even half of what that software will cost you. Over five years of use, maintenance and further development comfortably exceed the original build. That’s why “what happens after delivery, how many months of fixes are included, and at what rate afterwards” matters more than the price question.
The second hidden item is team dependency. Whoever built it holds the knowledge. Having the source code, the database schema and a “how to stand this up from scratch” document is not a negotiating point, it’s an ownership point. This is the digital half of your company’s assets — the asset inventory logic applied to software: if you don’t know what you own, you don’t own it.
The third option most businesses should take
The decision is presented as binary, but a third option usually works better: an off-the-shelf core with small custom pieces at the edge.
You buy the standard work — accounting, stock, e-documents. The one process that makes you different — the dispatch schedule, the field work order, dealer tracking, a particular report — you solve with a small piece of software at the edge and connect it to the core.
Why it usually wins: you don’t carry the regulatory burden of the standard side, the custom side stays small so it’s cheap to keep alive, and changing one side doesn’t bring the other down. Commissioning a complete system from scratch is, for most mid-size businesses, a bigger decision than the problem requires.
The scorecard (printable)
To make the decision discussable at the table, I put together a ten-question form. Each line is scored 1 to 5; the total shows which way you lean. Fill one in per process — not “for our company”.
📄 Buy or build — decision scorecard (PDF)
The form doesn’t make the decision; it makes visible what you are deciding on. Filled in together with the person who owns the process, the line you argue about most is usually the real knot in the job.
Three lines to write once you’ve decided
Whichever side you pick, three things should be in writing before the project starts. Projects that begin without them don’t finish — not for technical reasons, but for decision reasons.
1 · A stop criterion. By what date, and failing which result, do we stop this project? A criterion not written at the start never gets written; the project carries on under its own weight, because by then nobody wants to bear the cost of saying “let’s stop.”
2 · Data ownership. Can you export your data whenever you want, in a machine-readable format? Is it in the contract? The same question applies to bought and built alike.
3 · Pilot scope. Which single department, site or line goes first? Rolling out to the whole company at once is a decision that hides problems rather than fixing them: when everyone complains at the same time, you can’t tell which complaint is real.
How to read progress
What owners actually suffer with isn’t a technical failure. It’s losing sight of the work: where is it, what’s done, what’s waiting.
One rule is enough: progress is read from working software, not from a report. Nobody can verify a project that is “70% complete.” But ask for a fifteen-minute demo every two weeks, with real data on a real screen — that can’t be faked. If there’s a delay it shows up in the demo, and it shows up early.
A fixed half-hour weekly call and one three-column list (to do / doing / done) handles the rest. You don’t need a tool; being regular matters more than the tool.
Three common mistakes
- Asking for quotes without describing the process. If scope isn’t written down, quotes can’t be compared and everything outside it becomes a later invoice.
- Leaving users out of the decision. If the supervisor, foreman or field crew who will use the system isn’t in the selection, the system works on paper and not in the field.
- Saying “we’ll add that later.” Anything added later costs more than it would have if planned from the start. Write down what is in phase one and what is in phase two.
Fuat Çakır — industrial engineer and management consultant. He works on technology development, software project structure and supplier management in manufacturing and service businesses, and builds and ships his own mobile apps.
To put this decision inside a periodic review routine: the August business review — 8 things to check before Q4.
Frequently Asked Questions
How do I decide between off-the-shelf software and a custom build? Decide per process, not per company. One question: is this process where you differ from competitors, or is it what everyone in the industry does much the same way? Buy where everyone works the same way; build where your difference lives. For most businesses the right answer is a mix: an off-the-shelf core with small custom pieces at the edge.
What does custom software really cost? The build price is not even half the total. The real item is keeping it alive: bug fixes, operating-system and device updates, regulatory changes, new needs. When taking quotes, how many months of fixes are included after delivery — and at what rate afterwards — matters more than the price itself.
How do I know whether a software project is actually progressing? Not from a report, from working software. Ask for a fifteen-minute demo every two weeks, with real data on a real screen. Progress reported as a percentage can’t be verified; a demo can, and it surfaces delay early.