A finance director recently asked us a direct question: "Why would we build our own approvals system when we could buy one for a fraction of the cost?" It is the right question, and the honest answer is that for most companies, most of the time, buying is correct. The build vs buy decision is not ideological. It is a calculation, and it depends on one variable more than any other: how much the process in question resembles every other company's version of it.
Start with the process, not the software
Generic processes — standard expense reimbursement, basic ticketing, simple time tracking — are genuinely similar across companies. There is little advantage to be gained from doing them differently, so a mature off-the-shelf tool, configured well, is almost always the right answer. The economics favour buying: someone else has already amortised the development cost across thousands of customers, and you inherit years of edge-case handling for free.
The calculation changes when the process is not generic. A construction firm's site progress and materials drawdown process, a distributor's multi-tier vendor rebate structure, a services firm's project-to-invoice workflow tied to milestone billing — these are shaped by the specific way the business operates, and that shape is often where the business's actual advantage lives. Forcing a distinctive process into a generic tool means one of two outcomes: the process gets flattened to fit the software, eroding whatever made it work, or the team builds a shadow layer of spreadsheets and chat threads around the software to handle what it cannot — which is exactly the [operational debt](/insights/spreadsheet-operational-debt) pattern we see constantly.
A short diagnostic
- 01Does this process differ meaningfully from how a competitor would run it, or is it the same everywhere?
- 02If we changed how this process works, would customers or margins notice — or only our own team?
- 03Are we already spending real hours on manual workarounds because the current tool does not fit?
- 04Will this process still look roughly the same in three years, or is it likely to keep evolving as the business grows?
A process that scores as distinctive, workaround-heavy, and still evolving is a strong candidate for a purpose-built system. A process that scores as generic and stable is not — buy something mature and move on.
Why the old build-vs-buy math is outdated
The traditional case against building was cost and time: custom software took a year, needed a full engineering team, and carried maintenance risk long after the original developers moved on. That math assumed every project started from zero — its own database design, its own authentication, its own approvals engine, its own reporting layer, all written from scratch.
An AI-native approach changes that assumption. When the underlying platform already provides the connective tissue — data model, workflow engine, permissions, notifications, dashboards — building the distinctive parts of a process becomes a matter of configuration and targeted development rather than a from-scratch engineering programme. This is the core idea behind [what an AI-native business system actually means](/insights/what-ai-native-business-system-means): the expensive, generic 80 percent is already solved, so the investment goes into the 20 percent that is actually yours.
Where this shows up across functions
In procurement, a generic purchasing tool handles simple purchase orders well but struggles with multi-approver thresholds tied to project budgets — the kind of nuance [Procurement & vendor management](/solutions/procurement-vendor-management) is designed to absorb without forcing a workaround. In project delivery, off-the-shelf project management tools track tasks but rarely connect site progress directly to billing milestones, which is where [Project & workflow management](/solutions/project-workflow-management) earns its place. In sales, a standard CRM manages a pipeline, but if your sales process has an unusual credit-approval step before a deal can close, [Sales & CRM](/solutions/sales-crm) built around your actual sequence avoids the awkward bolt-on.
The maintenance question nobody asks upfront
Buying software does not eliminate long-term ownership cost — it converts it into subscription fees and configuration debt instead of engineering debt. Custom software does not eliminate it either — it converts it into a platform relationship instead of a vendor relationship. The relevant question is not "which option has zero ongoing cost" — neither does — but "which ongoing cost buys us something we actually value." Paying to keep a distinctive, advantage-generating process running well is a different proposition to paying licence fees for a process that looks the same as everyone else's.
A practical way to decide
We recommend mapping every core process on two axes: how distinctive it is, and how much manual workaround currently surrounds it. Processes that are generic and workaround-free stay on their current tools. Processes that are distinctive or workaround-heavy become candidates for a proper build. This mapping exercise, done honestly, usually takes a few hours and saves months of wrong-direction procurement. It is the first thing we do with any new client, described in more detail in [how we work](/how-we-work).
The build vs buy question will not disappear, and it should not — buying is frequently the right answer. But it is worth asking with the right variable in mind. The question is never "can we afford to build this," it is "is this the part of the business worth owning." For a growing number of SMEs, in a growing number of processes, the answer is yes.