Build or buy?
A decision usually made on price, better made on who owns the problem in three years.
Buy anything that is not a source of advantage. Build the thin layer where you are genuinely different, and make sure someone will own it.
Build-versus-buy is usually argued on cost, which is the least reliable basis for it. Both options are routinely presented with the uncomfortable half of the arithmetic missing, and the numbers that get compared are not comparable.
A more useful framing: every option leaves you holding a liability. Buy, and you hold a dependency on someone else's roadmap, pricing, and continued existence. Build, and you hold the obligation to maintain software for as long as you use it. Neither is wrong. The question is which one your business is better placed to carry.
The costs each side omits
Buying hides
- Configuration and implementation, often exceeding licence
- Per-seat growth as you hire
- The workarounds where it does not fit
- Migration cost if you ever leave
- Waiting on a roadmap you do not control
Building hides
- Maintenance, indefinitely
- Dependency and security updates
- The cost of the person who understands it leaving
- Everything the package included that you now build
- Time to first working version
Questions that actually settle it
- Would a customer notice if this worked exactly like everyone else's? If not, buy.
- Is there a package that fits, or only packages that could be made to fit?
- Who owns this in three years, and are they employed here today?
- What is the annual cost of the workarounds you run now? Put a figure on it.
- If this has to work in eight weeks, is building even available?
- If the vendor doubled its price, what would you do?
Most businesses need one custom system, not a custom everything. Identifying which one is the whole exercise.
Build vs buy — questions we get asked
Is custom always more expensive?
No. For a narrow, well-understood process, custom is often cheaper than per-seat licensing across a few years. It becomes expensive when scope is broad, because you are rebuilding what a package already gives you.
What if we build and the developer leaves?
Manage it before it happens: you own the code and repository, the stack is mainstream rather than exotic, documentation and handover are in scope, and deployment is reproducible. Ask for all four before you sign anything.
Can we start with a package and build later?
Yes, and it is often the sensible sequence — buy to get running, learn what genuinely does not fit, then build that specific piece and integrate. It beats deciding in the abstract.
The work this leads to
Replacing a spreadsheet that has become a system
When a workbook has become the system of record for a real process, the failure modes stop being inconvenient and start being expensive. Turning it into an application is usually a short project.
Read itImplementationSAP Business One, implemented properly
SAP Business One is rarely the problem. What decides the outcome is whether the process was agreed before configuration started, and who owns it afterwards.
Read itOther guides
Custom software or an off-the-shelf ERP?
A packaged ERP is the right answer more often than software firms admit. Here is how to tell which side of the line you are on, before anyone quotes you.
Cost guideWhat custom software actually costs to build
Most quotes cover version one. The questions that matter are what year two costs and what is excluded from the number you were given.
Still weighing it up?
Most of these questions are quicker to settle in a conversation than in an article — particularly the ones where the answer depends on your numbers.