The £40k MVP question: build, buy, or borrow?

Custom software is rarely the cheapest answer in year one. It's often the cheapest answer in year three. The question is whether you can wait that long, and whether off-the-shelf can carry you in the meantime.

This is the conversation we have on most discovery calls. The client has already half-decided to build, often because the SaaS options they've trialled were frustrating. Frustration is a signal, but it's not a strategy. The framework below is what we use to turn the frustration into a decision.

The three options

Buy , an off-the-shelf SaaS that solves 70% of the problem. Cheap, fast, generic. Your processes have to bend to fit it.

Borrow , assemble a workflow from no-code tools (Airtable, Retool, Zapier). Fast to stand up, surprisingly powerful for v1, gets expensive at scale.

Build , a bespoke system. Bends precisely to your processes. Slowest to launch, highest upfront cost, lowest run cost, fully yours.

Most real answers are a blend. A bespoke core wrapped around bought components (Stripe for billing, Resend for email, Supabase for auth) is almost always cheaper and more reliable than building everything from scratch.

When buy wins

When the problem is well-understood, widely solved, and not a competitive moat for you. Email, accounting, CRM basics, payroll. Don't build these. Ever.

The test: if losing this capability for a week would be annoying but not existential, buy it. If losing it for a week would stop the business, you might need to own it.

When borrow wins

When you don't yet know the answer. No-code lets you test five workflow ideas in a month for the price of one custom build. Brilliant for discovery. Treat it as scaffolding.

The trap with no-code is success. The prototype works, the team adopts it, and three years later you've got 40 Zaps held together by goodwill, two Airtable bases nobody understands, and a £3k/month tool bill. That's the moment to graduate to a custom build , and the borrowed system is now a perfect, working spec for it.

When build wins

When the workflow IS the business , when how you do this thing is part of what customers buy from you. When you're paying SaaS per-seat fees that scale linearly with revenue. When integrations between three tools are eating a person's full-time job.

Also: when compliance, data residency or audit requirements make off-the-shelf genuinely impractical. We've built tools where the deciding factor wasn't the workflow at all , it was that no SaaS vendor would sign the data processing agreement the regulator required.

The honest comparison

Get a £40k custom build quote. Then price the alternative: SaaS A + SaaS B + the Zapier glue + the part-time admin who keeps it running. Over 3 years, the gap is usually smaller than you'd expect.

Two costs people consistently forget: switching cost (the day SaaS A puts its prices up 40% and you have to migrate) and opportunity cost (the workflows you can't build on top because the vendor's API is locked down). Custom doesn't have these. That's a real number, even if it's hard to put on a spreadsheet.

The wrong reasons to build

"Nothing on the market does exactly what we want." Of course it doesn't. The real question is whether the gap matters enough to justify the cost.

"We want to own our IP." You can own a Notion workspace and an Airtable base too. Ownership of a thing nobody uses is worth nothing.

"Our processes are unique." Some are. Most aren't. Be honest about which is true for you , a five-minute audit against three competitors usually settles it.

A decision template

• Is the workflow a competitive moat? (If no , lean buy.)

• Do you know exactly what it should do? (If no , lean borrow.)

• Will it scale with revenue under a per-seat SaaS? (If yes , lean build.)

• Can you survive 8–12 weeks before v1 ships? (If no , borrow first, build later.)

• Will the workflow still look the same in 3 years? (If yes , build is safer than it looks.)

Score honestly. Most projects we end up taking on score 3-out-of-5 toward build , and the right answer is still to borrow for the first quarter, prove the workflow, then commission the build with a working prototype as the spec. Cheaper, faster, far less risk.