Build vs buy is the question that decides how much of your operating model you own, and most businesses answer it in the wrong room. It gets settled in a budget meeting, on the strength of a demo and a discount, months before anyone has written down what the software is actually for. The decision then quietly sets your cost base, your integration burden and your ability to change direction for the next five to seven years.

The modern version of build vs buy has a third answer. Alongside writing custom code and licensing a finished product sits low-code: platforms where configuration, visual modelling and a modest amount of scripting replace most of the engineering. That option is neither a cheap build nor an expensive purchase. It is a distinct category with its own economics, its own failure modes and its own ceiling, and treating it as a compromise between the other two is how organisations end up with a fourth outcome nobody wanted.

This guide sets out a practical build vs buy framework: what each route genuinely costs, the five tests that separate them, where low-code wins and where it collapses, and how to run the assessment in two weeks rather than two quarters.

Table of contents

Build vs buy vs low-code: what each option actually means

build vs buy vs low code decision framework b single funnel on plinth

Definitions drift in build vs buy conversations, and the drift is expensive. Two people can agree to “buy” while picturing entirely different commitments — one imagining a subscription that starts on Monday, the other a nine-month implementation with a systems integrator. Pin the terms down before the build vs buy options are compared.

Build: custom software you own outright

Building means specifying, designing and engineering an application against your own requirements, whether the team sits in-house, at an agency, or offshore. You own the source code, the roadmap and the technical debt. Nothing constrains the feature set except budget and skill, which is precisely the attraction and precisely the risk. A build is the only route that can encode a genuinely unusual process without compromise, and the only one where every future change is a project with a cost attached.

Buy: off-the-shelf products and SaaS

Buying means licensing software somebody else builds, maintains and improves. You are renting a shared roadmap. Your influence over it is proportional to your spend, which for most mid-sized businesses rounds to none. In exchange you get a working product immediately, a support contract, security patching you do not manage, and a per-seat cost that scales with headcount rather than with usage or value.

Low-code: assembled, configured and governed

Low-code platforms sit between the two. You model data, design screens and wire logic through a visual builder, dropping into code only at the edges. Read the neutral definition of a low-code development platform and the ambiguity becomes clear: the category spans everything from spreadsheet replacements to platforms running regulated processes. You own the application logic but rent the runtime it executes on. That single fact drives most of what follows.

Why the build vs buy question gets answered badly

build vs buy vs low code decision framework c stack of five slabs

The framework matters because the default build vs buy process is unreliable in a specific, repeatable way. Understanding the failure modes is most of the fix, and they show up in almost every post-mortem of a system that had to be replaced early.

The favourite vendor decides before the requirement exists

Someone has used a product before and liked it. That preference arrives in the room ahead of the requirement, and the evaluation quietly becomes a search for reasons to confirm it. A build vs buy decision made this way is not a decision at all — it is a procurement exercise dressed as one, and the alternatives receive perhaps an hour of genuine consideration between them.

Feature checklists hide the real cost

Scoring vendors against a 200-row feature matrix feels rigorous. It is not. Every serious product will tick almost every row, because the rows describe the category rather than your business. The matrix cannot distinguish a feature that works out of the box from one that needs six weeks of configuration, a partner engagement and a data migration. Cost lives in that distinction, and the checklist is blind to it.

Low-code is treated as a compromise rather than a category

The most common analytical error in build vs buy work is placing low-code on a line between the other two, as though it were a cheaper build or a more flexible purchase. It is neither. It has a different cost curve — low at the start, steepening sharply with user count and complexity — and a different risk profile. Comparing it on a single axis guarantees a wrong answer at the extremes.

Nobody owns the decision after it is made

Systems are chosen by committees and inherited by individuals. When the sponsor moves on, the rationale goes with them, and the next team sees only the cost line. Recording why an option won, against which tests, is what makes the choice defensible in three years — and what stops the same debate being reopened annually with no new information.

The five-test framework for a build vs buy decision

build vs buy vs low code decision framework d shield with keyhole

Five questions separate the build vs buy options more reliably than any feature matrix. Run them in order and the answer usually declares itself by the third. Score each one independently before discussing vendors, because naming a product early collapses the analysis into a preference.

Test one: is this process a differentiator or a commodity?

Ask what a customer would notice if this process were merely average. Payroll, expenses, helpdesk ticketing and general ledger are commodities — being excellent at them wins nothing, and a build here spends scarce engineering capacity on a solved problem. A pricing engine, a clinical scheduling algorithm or a proprietary underwriting workflow may be the business itself. Commodity points to buy; differentiator points to build; the large middle ground is where low-code earns its place.

Test two: how fast does the requirement change?

Stable requirements favour buying, because a shared roadmap is an asset when everyone wants the same thing. Volatile requirements — a process that changes with every regulation, contract or campaign — favour something you control. The relevant number is not how often the process changed last year but how often you wanted to change it and could not.

Test three: where does the data boundary sit?

Map which systems this application must read from and write to, and how current that data has to be. An application that needs live access to three internal systems and a warehouse is an integration project regardless of route, and the integration usually costs more than the application. Products with a genuine API and documented webhooks are worth a premium; products that export a nightly CSV should be scored as a build with extra steps.

Test four: who owns it in three years?

Every build vs buy route creates an ownership obligation, and the honest question is whether you will staff it. A build needs developers who understand the codebase. A purchase needs an administrator who knows the configuration. Low-code needs both a platform owner and a governance process. Choosing a route your organisation cannot staff is the most reliable way to end up with an unmaintained system and no budget to replace it.

Test five: what does being wrong cost?

Finally, price the reversal. If this choice proves wrong in eighteen months, what does it take to undo? A SaaS product with clean data export and a twelve-month term is a cheap mistake. A deeply customised platform with three years remaining and no export path is an expensive one. Weight the build vs buy tests by that number — reversibility is worth more than any single feature.

Total cost of ownership across build vs buy and low-code

build vs buy vs low code decision framework e two rings around cube

Comparing a build quote against an annual subscription is the single most common arithmetic error in build vs buy work. One is a capital-shaped number and the other is an annuity, and they only become comparable across a defined horizon — five years is the usual choice. A proper total cost of ownership model includes the lines below on every route, not just the obvious one.

The upfront number and the drift behind it

A build front-loads its cost: discovery, design, engineering, testing, deployment. Buying front-loads far less but rarely stays flat. Per-seat pricing rises with headcount, tiers gate the features you eventually need, and the modules that made the business case are frequently priced separately. Model the subscription at your projected year-five headcount and tier, never at today’s, and the two curves often cross earlier than expected. Our breakdown of custom software development cost sets out what the build side of that curve actually contains.

The maintenance line nobody budgets

This is the line that most often decides a build vs buy comparison. Custom software needs roughly fifteen to twenty-five per cent of its build cost every year simply to stand still — dependency updates, security patches, platform migrations, browser changes and small fixes. Teams that omit this line do not avoid the cost; they defer it until the application is three major versions behind and the upgrade becomes a rebuild. Bought software includes this in the subscription, which is a substantial and frequently unacknowledged part of its value.

Configuration is not free on any route

Low-code’s headline economics assume the platform fits. Configuration effort, environment management, connector licences and the specialist who understands the platform are all real costs, and they arrive whether the platform is billed per user or per application. Budget them explicitly rather than filing them under “admin”, because they are the line that most often turns a cheap low-code project into an average-priced one.

Exit costs and switching friction

Ask every vendor, and every internal team, the same question: what does leaving look like? A documented export in an open format is worth real money. Proprietary formats, embedded business logic and data models nobody outside the platform can read are a liability that compounds with every month of use. Price the exit before signing — no build vs buy model is complete without it, and it is never cheaper to negotiate afterwards.

Where low-code genuinely wins

build vs buy vs low code decision framework f gear meshing with block

Low-code deserves its own analysis in any build vs buy exercise rather than a footnote. There is a class of problem it solves better than either alternative, and recognising that class quickly is worth more than any platform comparison.

Internal tools with modest user counts

Approval flows, inspection forms, asset registers, onboarding trackers, request queues. These applications have real business value, straightforward logic and a bounded audience — typically tens of users rather than thousands. A build is disproportionate; no product fits closely enough; low-code lands precisely in the gap and delivers in weeks. This is the band where a build vs buy analysis run on two options alone gives the wrong answer.

Glue between systems of record

Much operational pain is not missing software but disconnected software. Low-code platforms are unusually good at sitting between an ERP, a CRM and a finance system, moving records and enforcing a process across them. This is also where they overlap with workflow automation and broader business process automation work, and where the return arrives fastest.

Iteration speed with the people who own the process

The strongest argument for low-code is not cost but feedback latency. When the operations manager who owns a process can watch a change appear the same afternoon, requirements improve rapidly, because they are being tested rather than imagined. That loop is genuinely hard to replicate through a conventional development cycle.

Proving a concept before committing capital

Low-code is an excellent way to de-risk a build. Model the process, run it with real users for a quarter, and you learn what the requirement actually is. If it outgrows the platform, you rebuild from a specification proven in production rather than one written in a workshop — which is the cheapest requirements document available.

Where low-code quietly fails

The failure modes are as predictable as the wins, and they rarely appear during a pilot — which is why a build vs buy evaluation should stress them deliberately. Each one shows up months later, when the application has become load-bearing and the cost of moving is highest.

Licensing economics invert at scale

Per-user pricing that looks trivial for forty users can become the largest line in an IT budget at four thousand. Low-code platforms are priced for departmental use and monetise success. Before building anything customer-facing or company-wide, model the licence cost at full rollout — this is the single most common route to an unpleasant renewal.

Governance, sprawl and shadow IT

The property that makes low-code fast — anyone capable can build — is the property that produces two hundred undocumented applications, half abandoned, several holding personal data nobody has catalogued. Without an owner, an environment strategy and a register, the platform stops being an asset. Governance is not optional overhead here; it is the cost of the speed.

Complex logic and performance ceilings

Visual builders handle branching approval logic elegantly and intricate algorithmic work poorly. Applications with heavy computation, unusual data structures, sub-second response requirements or very high transaction volumes hit a ceiling that no amount of platform expertise removes. The warning sign is a growing volume of custom script inside the low-code app — at that point you are building, with constraints and a licence fee, and the build vs buy question deserves reopening.

Version control and testing discipline

Mature engineering practice — branching, code review, automated regression tests, staged environments — is standard in a build and variable in low-code platforms. Some support it well; some barely at all. When an application matters, the absence of a rollback path is a serious operational risk, and it is worth testing during evaluation rather than discovering during an incident.

Risk, compliance and security in the build vs buy decision

Security and regulatory obligations rarely change the build vs buy answer outright, but they reliably change the weighting — and they are cheapest to consider before a contract exists rather than during an audit.

Responsibility is split differently on each route

Buying transfers a great deal of the cybersecurity workload to the vendor: patching, infrastructure hardening, certifications, penetration testing. It does not transfer accountability. You remain responsible for the data, the access model and the consequences. Building keeps every layer in-house, which suits organisations with the capability and punishes those without. Low-code splits it — the platform is hardened for you, the application logic and permission model are entirely yours, and that boundary is where most incidents occur.

Supply chain and concentration risk

Each purchased product is a supplier dependency, and dependencies aggregate. The NCSC’s supply chain security guidance is a sound basis for assessing them proportionately. Concentration deserves specific attention: a single platform hosting thirty business-critical applications is a different risk from thirty separate tools, better in some respects and considerably worse in others.

Data residency and processor obligations

Establish where data will be stored and processed, who sub-processes it, and what the contract says about breach notification and deletion. For UK organisations handling personal or regulated data this is a gating question, not a preference — and it disqualifies options quickly enough that it belongs early in the process rather than in a final legal review.

Continuity when a vendor fails

Ask what happens if the vendor is acquired, changes direction or ceases trading. Escrow arrangements, export guarantees and documented recovery procedures matter more for the systems your operations depend on daily. This is ordinary vendor management discipline applied at the point of selection, where it costs nothing, rather than at renewal, where it costs leverage.

Running the build vs buy assessment in practice

A structured build vs buy assessment takes about two weeks of part-time effort. Longer build vs buy evaluations rarely produce better answers; they produce more documentation and a stale market view.

Week one: define the problem without naming a product

Write the process as it runs today, including the workarounds. Identify the twenty per cent of requirements that are genuinely non-negotiable and mark everything else as desirable. Establish the integration map and the realistic user count at year three. Nothing here mentions a vendor. This is essentially a compressed software discovery phase, and skipping it is what makes evaluations circular.

Week two: test the shortlist against your own data

Take two or three candidates — ideally one per route — and run each against a real scenario with real records, not the vendor’s demo data. Ask each to demonstrate the awkward requirement, not the impressive one. For the build option, get an indicative estimate against the same scope from a custom software development company so the comparison is like for like.

Score openly and record the reasoning

Weight the five tests, score each option, and write a one-page build vs buy decision record: what was chosen, what was rejected, on which evidence, and what would have to change to revisit it. That page is the highest-return artefact of the entire process, and it takes an hour.

Who belongs in the room

The process owner, someone accountable for the budget over five years, and someone who will support the system afterwards. Three people with the right knowledge decide better than eleven with opinions, and the third seat is the one most often left empty.

Hybrid architectures: buy the core, build the edge

Framing build vs buy as a single choice for a whole business is itself a mistake. Mature organisations answer it per capability, and the resulting architecture is usually mixed by design rather than by accident.

Buy the commodity core

Finance, HR, email, collaboration and CRM are bought by almost everyone for good reason. These are solved problems with mature products, and a business that builds its own general ledger has misallocated its engineering capacity in a way that will take years to unwind.

Build the differentiating edge

Reserve custom development for the small number of capabilities that make you distinctive — this is where a build vs buy analysis should land on build without hesitation. This is also where a staged approach pays: proving the concept through MVP development services before committing to a full build keeps the expensive route pointed at a validated requirement.

Use low-code as connective tissue

Between a bought core and a built edge sits a large amount of process work — approvals, exceptions, handoffs, internal tooling. That is low-code’s natural territory, provided it is governed. This layered pattern also ages well: replacing one layer does not require touching the others, which is exactly the reversibility test five asks for.

Keep integration a first-class concern

Whatever the mix, integration is where hybrid architectures succeed or fail. An API-first selection policy, a documented data model and a deliberate digital strategy for how systems exchange information matter more than any individual product choice.

Build vs buy mistakes that cost the most

Some build vs buy errors are recoverable and some are not. These are the ones that reliably prove expensive, drawn from what actually goes wrong rather than what evaluation templates warn about.

Comparing a build quote to a monthly subscription

The arithmetic error described earlier is worth repeating because it is so common. Always compare across the same horizon, with maintenance, licences, internal effort and exit costs included on every route. A build vs buy comparison without a five-year model is not a comparison.

Buying a platform to solve a process problem

If the process is broken, software will encode the breakage faithfully and at speed, whichever side of build vs buy it came from. Fix or at least document the process first. This is the most expensive mistake in the entire category, because it is invisible until go-live and is then blamed on the software.

Ignoring the people cost of change

Every build vs buy route requires migration, training and a period of reduced productivity. Buying does not eliminate this; it frequently increases it, because the product’s model must be adopted rather than adapted. Budget for adoption explicitly.

Deciding once and never revisiting

The correct build vs buy answer changes as products mature, headcount grows and requirements settle. A build vs buy decision made three years ago on a system now costing four times its original licence deserves review — set a date at the point of decision, and let the decision record tell you what to re-test. For a closer look at one axis of this question, our earlier comparison of no-code and low-code against custom development covers the trade-offs in more depth.

Reaching a defensible answer

The build vs buy question has no universal answer, which is why frameworks beat rules of thumb. What it has is a reliable method: define the problem before naming a product, run the five tests, model five years rather than one, and treat low-code as its own category with its own ceiling instead of a midpoint between the alternatives.

Applied honestly, the build vs buy framework usually produces an unglamorous conclusion — buy most of it, build the small part that matters, assemble the connective layer on low-code, and write down why. That answer is rarely exciting and is almost always cheaper than the alternative, which is discovering the reasoning three years later when the renewal arrives and nobody can remember what was decided or why.

If you are working through a build vs buy decision now, the most useful next step is the two-week assessment above. It costs very little, it is repeatable, and it replaces the loudest opinion in the room with evidence.