Build vs. Buy: The Decision That Kills More Startups Than Either Choice

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A UK-based seed-to-Series-A founder who has priced up a SaaS tool that covers 70% of their need and is now deciding whether to pay £18K–£40K/year in subscriptions or commission a custom build — and has no neutral framework to make the call before their next board meeting

If a SaaS tool covers 70% of what you need and the subscription sits in the £18K–£40K range, the honest answer is: buy it, but only if you can live with the 30% gap for the next 18 months without commissioning middleware to fill it. The moment you start paying a vendor's professional-services team or an integration partner to close that gap, the cost advantage of buying evaporates — usually around month 18–24, right when your first renewal lands with a double-digit uplift. The framework below is how to work out which side of that line you're on before you sign.

This decision kills more early-stage companies than either choice on its own, because the failure mode isn't the build or the buy — it's picking one, discovering 10 months in that it was wrong, and then having to unpick it with runway you no longer have. Forrester's 2024 Software Development Trends Report found that 67% of failed software implementations trace back to an incorrect build-vs-buy decision, not to execution problems downstream.

Why the vendor's TCO calculator lies to you (not maliciously, but structurally)

Every SaaS vendor's ROI model assumes list price, standard seats, no add-on modules, no AI usage charges, and renewal at the same rate. Reality looks nothing like that.

• 79% of IT leaders saw a SaaS price increase at renewal in the past 12 months, and 77% hit unexpected costs after signing.
• SaaS list prices rose roughly 11.4% year-over-year in 2025 — about 4–5× G7 inflation.
• Once you add modules, AI usage, minimum-seat requirements, and tier migrations, effective annual cost increases often sit in the 20–30% range.
• The headline subscription typically accounts for only 50–70% of true annual cost once implementation, integration, training, and renewal uplifts are counted.
• Gartner research cited in VendorBenchmark's analysis finds integration and management costs alone represent 30–40% of SaaS spend for organisations running eight or more tools.

The build side has a mirror problem. Founders model the build cost and forget the tail. Forrester's Total Economic Impact work suggests 78% of lifetime software costs accrue after launch — maintenance alone typically runs 15–20% of original build cost per year. A £120K build is a £36K-a-year ongoing commitment before you've shipped a new feature.

So neither side is quoting you the real number. The framework has to normalise both.

Define the decision crisply

The question is not "should we build or buy?" It is: Which option gives us the lowest total cost of ownership and the highest optionality over a 36-month horizon, given that we will almost certainly change our mind about something in month six?

If you can't answer in those terms, you're not ready to decide — you're ready to scope. Spend a week doing the five-axis scoring below before you take anything to the board.

The five axes that actually decide it

1. True 36-month TCO, not year-one sticker price

Model both options over 36 months with these line items made explicit:

Buy side: year-one subscription, implementation fees, integration/middleware to close the 30% gap, training, admin time, year-two and year-three renewal uplifts (assume 15–25% compound based on the figures above unless your contract caps them), and any per-seat uplift as headcount grows.

Build side: initial build, 15–20% annual maintenance, hosting/infrastructure, one engineer's worth of ongoing attention (even if distributed), security patching, and the cost of the two features you haven't thought of yet (add 25% contingency).

Illustrative worked example — a UK Series A fintech comparing a £28K/year workflow SaaS vs a custom build:

• Buy, 36 months: £28K + £35K (implementation and integration to fill the gap) + £32K year two (15% uplift + two added modules) + £37K year three = ~£132K, assuming no major re-platforming and no per-seat explosion.
• Build, 36 months: £140K initial build + £25K/year maintenance × 2 = ~£190K, with full IP and no renewal risk.

Every number above is illustrative and assumes a two-integration scope, no data migration from a legacy system, and a team of under 50 users. Change any of those and the ranking flips. What would turn this into a real comparison for your business: your current and projected seat count, how many systems the tool needs to talk to, and whether the 30% gap is cosmetic or workflow-critical.

2. Speed to first value

Buy wins here, almost always. A SaaS tool delivers value in weeks; a custom build delivers value in months. If you need the capability live before your next funding round or before a specific customer contract starts, that often decides it on its own.

The nuance: "value" is not "logged in." If the 30% gap means your team is running parallel spreadsheets to work around the tool, you haven't delivered value — you've added a system of record that doesn't record everything.

3. Key-person and vendor risk

Buying concentrates risk in the vendor. Building concentrates it in the two engineers who understand the codebase. Both are real; neither is cheaper by default.

Vendor risk gets underpriced because it feels diffuse. It isn't. Only 23% of SaaS contracts contain an explicit data-portability clause, and only 42% acknowledge GDPR Article 20 obligations at all. If your vendor is acquired, pivots upmarket, deprecates the module you depend on, or triples the price at renewal, your options are: pay, migrate (expensive), or lose the data.

Key-person risk gets underpriced on the build side because founders assume the original engineers will stay. They mostly don't, past 24 months. Mitigation is documentation discipline and a partner (internal or external) who can pick up a codebase cold — which is a capability, not a hope.

4. What happens if you change your mind in month six

This is the axis most frameworks ignore. Ask: if we decide in month six that this was wrong, what does the reversal cost?

• Buy → rebuild: you lose the subscription spend to date, pay exit fees if your contract allows them, and face a data-extraction fight. Under UK GDPR Article 20, the right to portability covers only data the data subject provided — not derived or inferred data such as analytics, scores, or behavioural segments. The business intelligence your team generated inside the tool may not be yours to take.
• Build → buy: you've spent the build budget, but you own the IP and the data, and you can run both in parallel during migration. The sunk cost stings; the optionality is intact.

Reversibility is asymmetric. Buying feels low-commitment and is often the hardest to reverse. Building feels high-commitment and is often easier to walk away from.

5. Strategic differentiation

If the software is the product, or materially shapes how customers experience the product, buy loses by default — you cannot differentiate on infrastructure your competitors can also buy. If it's back-office (payroll, expense management, CRM for a 12-person sales team), buy wins by default — nobody is going to award you a customer because your expense tool is bespoke.

Most decisions sit in the messy middle. The test: would a customer notice if this capability was 20% better than the competition's? If yes, lean build. If no, lean buy.

Scoring the options honestly — including the case against both

The case against buying

Renewal cycles compound. The 30% gap rarely closes — vendors prioritise features that sell to new logos, not features that fix workflow quirks for existing customers. Data portability is weaker than most buyers realise. You are optimising for speed-to-value today and absorbing optionality cost later.

The case against building in-house

You are hiring a team to maintain software that is not your product. You take on recruitment risk, retention risk, and the hidden cost that whenever those engineers are fixing an internal tool, they are not building what customers pay you for. Build-in-house makes sense when the software is strategic and when you have the engineering management bandwidth to run a second product organisation.

The case against commissioning a build from a partner

You are trusting a third party to deliver fixed-scope on a timeline that will almost certainly need to flex. The quality of the partner matters more than the price. A cheap bad build is the most expensive outcome in the whole framework — you pay for the build, pay to maintain the mess, and eventually pay to replace it. Due-diligence the partner's handover discipline, documentation standards, and IP terms (full IP transfer with no vendor lock-in should be table stakes, not a selling point).

The case against doing nothing this quarter

Sometimes it is the right call. If the 30% gap is painful but survivable, if your runway is tight, and if the capability isn't on the critical path for the next 6 months, waiting a quarter to make a better-scoped decision costs less than making a wrong one now.

If you're in situation A, do X

Situation A: Back-office capability, non-differentiating, under 30 users, standard workflows

Buy. Negotiate a 24-month term with a capped renewal uplift (push for CPI + 3%, settle for CPI + 5%), an explicit data-portability clause covering derived data, and exit assistance. Do not commission middleware to close the 30% gap in year one — adapt the workflow instead. Revisit at renewal.

Situation B: Workflow-critical, the 30% gap breaks the process, you'll grow past 100 users in 18 months

Build, but incrementally. Buy the SaaS tool for 12 months to buy time, and run a parallel build that replaces it module by module. Do not try to build the whole thing before switching. This is the "incremental modernization" pattern — it costs more in the short term and far less across 36 months.

Situation C: The capability is part of your product or materially shapes customer experience

Build, from day one. This is not a buy decision in disguise. Scope it tightly, ship a thin version in 10–14 weeks, and iterate. If you don't have the in-house team, a fixed-scope delivery partner is usually faster and lower-risk than hiring, especially pre-Series B when every hire is a 12-month commitment.

Situation D: You genuinely cannot tell which situation you're in

Wait a quarter. Spend the quarter scoping — talk to three customers about what they'd notice, model the 36-month TCO for both options with real numbers, and get a lawyer to read the SaaS MSA. A deferred decision made with better information beats a confident decision made with the vendor's slide deck.

What belongs in the board paper

Three things, in this order:

1. The 36-month TCO for both options, with every assumption listed in the same paragraph as the number.
2. The reversibility cost in month six for each option — cash and calendar.
3. The two or three specifics that would change the recommendation. For most decisions, those are: projected seat count at month 24, whether the 30% gap is workflow-critical or cosmetic, and whether the data generated inside the tool is strategic to the business.

If the board paper doesn't contain all three, you are presenting a preference, not a decision. On the contract side specifically, a solicitor familiar with UK GDPR and SaaS MSAs should review any portability, exit-assistance, and renewal-cap language before signature — the clauses that matter most are the ones vendors least want to negotiate.

Frequently Asked Questions

How do I calculate the real total cost of ownership of a SaaS tool before signing?

Start with the three-year subscription at a 15–25% annual uplift (based on the renewal data cited above), then add implementation, integration or middleware to close any functional gap, training, admin time, and any per-seat uplift as headcount grows. The headline subscription typically ends up being 50–70% of true annual cost once all of that is counted. Ask the vendor explicitly what you pay if you add 50% more seats, add two modules, and renew at year two — in writing.

At what point does building custom software become cheaper than paying for SaaS?

The crossover usually sits somewhere between month 18 and month 30, driven by three variables: how fast per-seat costs scale with your growth, how much you spend on middleware or professional services to close the functional gap, and the compounding effect of renewal uplifts. If any one of those three is severe, the crossover moves earlier. The honest way to find your crossover is to model both options over 36 months with your actual seat and integration numbers, not the vendor's.

What are the biggest hidden costs when commissioning a custom build?

Ongoing maintenance (typically 15–20% of the original build cost per year), hosting and infrastructure, security patching, the engineering management time to run a second product org if you build in-house, and the two or three features you haven't thought of yet. Forrester's analysis suggests roughly 78% of a software product's lifetime cost accrues after launch, so any budget conversation that stops at the build price is incomplete.

Can my SaaS vendor legally stop me taking my data out at the end of the contract?

Under UK GDPR Article 20, data subjects (not businesses) have a right to portability for data they provided — but that right doesn't cover derived or inferred data such as analytics, scores, or behavioural segments. For business data at contract end, your rights come from the contract itself, and only around 23% of SaaS contracts include explicit data-portability clauses. If your contract is silent, the vendor can legitimately charge for extraction. A solicitor should review the exit-assistance and data-portability language before you sign — not after.

How long does a custom build actually take for a startup replacing a SaaS tool?

It depends almost entirely on scope, number of integrations, whether you're migrating data from an existing system, and how settled your workflow is. A thin first version replacing one workflow is a very different project from a full feature-parity rebuild. The variables that turn a range into a real timeline are: how many systems it needs to talk to, how much historical data has to move, and whether the workflow is already stable or still evolving. Those are the three questions worth answering before you ask any partner for a timeline.