The decision between building custom software and buying an off-the-shelf solution is usually treated as a price comparison: the product licence costs X per month, development costs Y — and Y is almost always higher. Framed that way, the answer looks obvious. And that's exactly why so many companies find themselves, three years later, paying rising licence fees for a system the entire operation has learned to work around with spreadsheets.
The problem isn't the maths. It's that the comparison is being made on the wrong variable, over the wrong horizon.
The question that decides it: is the process a commodity or a differentiator?
Before any financial analysis, one question resolves most cases: is the process this software will support the same as your competitors', or is it part of what makes your company win business?
Commodity processes — accounting, payroll, tax filing, corporate email — run essentially identically at any company in your sector. There's no competitive advantage in doing them "your way". For these, buying is almost always the right answer: the vendor spreads development cost across thousands of customers, keeps regulatory compliance current, and delivers a more mature product than any in-house build would reach.
Differentiating processes are the opposite: the specific way your company prices, serves, routes, staffs or manages projects differs from competitors — and that difference is part of the outcome. When off-the-shelf software forces that process to adapt to the product, the company isn't saving on technology. It's paying, in competitive advantage, for a discount it received on licensing.
It's the same logic we cover in when an off-the-shelf ERP stops working: the ERP doesn't fail on standard processes — it fails exactly on the processes that make the company what it is.
The right comparison: 3–5 year TCO, not year-one price
The honest comparison between building and buying isn't monthly licence vs. development budget. It's total cost of ownership over the horizon the software will live for — typically 3 to 5 years.
On the off-the-shelf side, total cost includes:
- Licences that scale — per user, per module, per transaction volume. The entry price is rarely the year-three price: the company grows, user count grows, and modules that looked optional become necessary.
- Process-adaptation cost — training, rework, productivity loss during the adjustment period and, worse, the permanent concessions the operation makes to fit the product.
- Integrations — connecting the off-the-shelf product to existing systems is rarely included in the licence. Connectors, middleware and implementation consulting all add to the bill.
- Unused functionality — most companies use a fraction of the modules they pay for. That waste is invisible because it's bundled into the package.
On the custom-software side:
- Higher upfront investment — there's no spreading it out: development is paid for by whoever commissions it.
- Maintenance and evolution — typically 15–20% of the initial investment per year, predictable and under the control of whoever decides what evolves.
- No per-user cost — the system costs the same with 20 or 200 people using it.
Put on the same horizon, the two paths cross — and the crossover point usually falls between year two and year three for operations that are growing or have a specific process. Before that, off-the-shelf is cheaper. After it, the licence curve keeps climbing while custom software amortises.
This doesn't mean building "always pays off in the long run". It means a decision made on year-one price alone is being made with a third of the information.
The costs that appear in no proposal
Two costs rarely make it onto the comparison spreadsheet — and they're the ones that weigh heaviest on anyone who has already been through a system switch.
The first is lock-in. The more the operation adapts to a product, the more expensive it becomes to leave it. Data in a proprietary format, integrations built on the vendor's API, staff trained on the tool, processes redesigned to fit the product: every year of use raises the cost of switching. The licence price may be fixed; the cost of dependency compounds.
The second is the cost of the exception. Off-the-shelf software is designed for the average case. Real operations run on exceptions — the client who negotiates special terms, the project that changes scope, the order that needs invoicing in an unusual way. When the system doesn't support the exception, it moves outside the system: spreadsheet, email, WhatsApp, someone's memory. That's how the parallel controls we describe in when the spreadsheet becomes the management system are born — and their cost never appears on the software invoice.
When buying is the right answer
An honest framework also has to say when not to build. Buying is the right decision when:
- The process is a commodity. Accounting, HR, tax, a simple standard-funnel CRM: mature products do this better and cheaper than any development effort.
- The urgency is real. If the operation needs the capability within weeks, an off-the-shelf product delivers in weeks. Development delivers the first module in two to four months.
- The volume doesn't justify it. A five-person team with a simple process doesn't amortise development — the TCO maths favours the licence for a long time.
- The process is still forming. A young company still discovering how it operates benefits from adopting the built-in practices of a good product, rather than crystallising an immature process into code.
When building is the right answer
Building custom is the right decision when three conditions stack up:
- The process is a differentiator — the specific way the company operates is part of the competitive advantage, and adapting it to a generic product would cost that advantage.
- Scale amortises it — the number of users, the volume of operation or the cost of current inefficiencies make the TCO crossover visible within a 2–3 year horizon.
- Integration is structural — the system needs to talk deeply to the ERP, shop floor, CRM and existing tools, and off-the-shelf connectors don't cover the case. As we show in enterprise web applications: when to build instead of buy, integration is usually the factor that rules out the off-the-shelf product before price even enters the picture.
In that scenario, custom software isn't an engineering luxury — it's how technology ends up serving the process, rather than the other way round.
The path most companies overlook: hybrid
The decision is rarely binary. The most rational architecture for most mid-sized companies is hybrid:
Buy the commodity core. Build the differentiating edge.
The ERP keeps handling accounting, tax and payroll — nobody should be building that. Around it, the processes that differentiate the operation — pricing, project budgeting, customer journey, staff allocation, management cockpit — are built custom and integrated to the core.
This architecture captures the best of both sides: the maturity and diluted cost of the product where it's standard, and full fit of custom software where it's strategic. And it avoids the worst of both: neither heavy ERP customisation (expensive, fragile and hostage to consulting) nor reinventing the tax module.
How to decide in practice: five questions
Before signing the licence or approving the development budget, answer in writing:
- Is this process the same as competitors'? If yes, buy. If it's part of what makes the company win, move to question 2.
- What's the real TCO of both paths over 4 years? Include user growth, future modules, integration and training — not just the entry price.
- What will the operation stop doing its own way to fit the product? List the concessions. If the list includes what differentiates the company, the licence discount is expensive.
- How many parallel controls will the current system (or the product being evaluated) generate? Every workaround spreadsheet is a symptom of misfit — and an invisible recurring cost.
- What's the cost of leaving in 3 years? If the answer is "impractical", the licence price isn't the real price.
If the answers point to building — or to hybrid — the next step isn't a budget: it's a diagnosis. Mapping the real process, the required integrations and the scope of the first module that delivers usable value in production.
Sparsum in practice
In the projects that reach Sparsum, the pattern repeats: the company isn't looking for development because it wants software — it's looking because the product it bought stopped keeping pace with the operation.
In a services operation with strong seasonality, the off-the-shelf management system charged per user and required staff allocation to follow the product's model. The company operated on its own scaling model — which was exactly its margin differentiator. The custom system we built encoded that model, integrated with the existing ERP for billing, and eliminated the four spreadsheets that bridged the gap. The cost crossover with the previous licence happened in month twenty-six.
At another company, an industrial one, the answer was hybrid: the ERP stayed put, handling the tax and accounting core, and the custom system covered technical budgeting and project tracking — the two processes the entire market was doing in Excel because no product served them.
In both cases, the decision didn't start with technology. It started with the question this article opened with: what, in your operation, is a commodity — and what's the reason clients choose you?