A client rang me in 2021 — proper panic in his voice. He'd spent £140,000 over fourteen months building a custom invoicing platform. His dev team had shipped maybe 60% of the spec. And somewhere around month eleven, he'd discovered thatInvoice Ninjaexisted, was open-source, and did 90% of what he needed out of the box. For free.
That call haunts me a little. Because the honest answer is: I've made the opposite mistake too. Seahawk had a project in 2019 where we spent eight months stitching together five different SaaS tools — Airtable, Zapier, Typeform, HubSpot, and a custom Webflow CMS — to manage a client workflow that, in retrospect, a £15,000 custom build would have solved cleanly and permanently. We were paying roughly £900/month in combined subscriptions by the end of it. Do the maths over three years.
Neither extreme is automatically right. And anyone selling you a clean rule — "always build", "never build" — is selling something. So here's the actual framework I use when a founder sits down with me and asks the question.
---
First, Admit What You're Actually Deciding
This isn't a technical decision. Not really. It's a business decision dressed up in technical clothes.
When you say "should I build or buy?", what you're actually asking is: where does differentiation live in my product? If the thing you're considering building is core to your competitive advantage — thereasoncustomers will choose you over the next tab in their browser — then building probably makes sense. If it's infrastructure, admin, or commodity functionality, buying is almost certainly cheaper in real terms.
I ask founders one question first:Will your users ever see this thing?If the answer is yes and it shapes their experience in a meaningful way, it might be worth building. If it's back-office, operational, or internal, the bar for building should be very high.
---
The Real Cost of Building (People Underestimate This Badly)
Let me be blunt. Custom development costs more than you think, takes longer than you're told, and requires ongoing maintenance that nobody budgets for.
What founders actually forget to price in
- Maintenance and hosting.Not a one-off. You're on the hook forever unless you sunset the thing.
- Security patches.A SaaS vendor handles this for you. You build it, you own it, including the 2am alerts.
- Onboarding new devs.If your lead engineer leaves, the next person needs to learn your codebase. That's weeks of billable time.
- Feature creep.Stakeholders see a custom tool and assume it can do everything. Scope expands. Costs follow.
A rough rule I use: take your initial dev estimate, multiply by 1.6 for realistic delivery, then add 20% of that number annually for maintenance. If those numbers still make the business case, great. If they don't, you have your answer.
Honestly, theStandish Group's CHAOS Reporthas been showing for decades that software projects overrun their budgets at an alarming rate. The number sits around 45-50% of projects being "challenged" or outright failing. That's not a reason to never build — it's a reason to go in clear-eyed.
---
The Real Cost of SaaS (Also Underestimated, Just Differently)
SaaS looks cheap until it doesn't.
The £49/month plan that seemed reasonable at the start of the year has a funny habit of becoming £490/month by year three — once you're on a higher tier, you've added seats, and the vendor has done a "pricing restructure" (read: increase). I've watched this happen to clients on Salesforce, Intercom, and Mixpanel. It's not malicious. It's just how SaaS economics work.
The three SaaS traps founders fall into
- Vendor lock-in.Your data is in their format, their schema, their export flow. Leaving is painful and sometimes effectively impossible without significant data engineering work.
- Franken-stack complexity.Five tools that sort-of integrate via Zapier is not a system. It's a liability. One API deprecation and things start falling apart.
- Subscription creep.Nobody audits their tool stack annually. They should. I ran an audit for a 12-person agency last year and found £3,200/month in SaaS they'd either stopped using or were using for one feature each.
That said — for commodity functions, SaaS is almost always the right call. Email delivery?Postmarkor SendGrid. Payments? Stripe, obviously. Auth? Auth0 or Clerk. Nobody should be building their own payment processor in 2024.
---
A Framework That Actually Works
Right. Here's how I think through it. Four questions, in order.
Question 1: Is this a competitive differentiator?
If yes — if this is the thing that makes your product genuinely different — building is worth serious consideration. If no, stop here. Buy.
Question 2: Does a good-enough SaaS alternative exist?
Good-enough, not perfect. Founders routinely build because "nothing out there does exactly what we need." Sometimes that's true. Often it means they haven't looked hard enough, or they're confusing "we need to configure this well" with "we need to build something new."
I spend at least two hours researching the SaaS market before I'd ever recommend a custom build.Product Huntand G2 are genuinely useful here — not as gospel but as a starting inventory.
Question 3: What's your realistic time-to-value?
A SaaS tool can be live today. A custom build is weeks at minimum, usually months. If speed matters — and in early-stage companies it almost always does — buying buys you time to learn what you actually need before you commit to building it.
Back in 2022, Seahawk worked with a logistics startup that wanted a custom route-optimisation dashboard. We talked them into using a white-labelled API layer first (they usedRoute4Meas a starting point). Six months later, they knew exactly which three features their customers actually cared about. The custom build they eventually commissioned was half the scope — and twice as good — because they'd learned in production rather than in a spec document.
Question 4: What happens when this breaks?
Because it will break. The question is who fixes it and how fast. With SaaS, you file a support ticket and complain on Twitter. With custom software, you call your dev team. If you don't have a dev team retained, you're in trouble. That's not a hypothetical — I've seen founders stuck with broken custom software for weeks because their freelance developer went on holiday.
---
When Building Is Clearly the Right Call
There are situations where custom is obviously correct. Let me name them plainly.
- Your core IP is the software itself.If you're selling a SaaS product, you can't outsource the thing you're selling.
- Regulatory requirements mean off-the-shelf won't cut it.Certain fintech, healthcare, and legal applications have compliance constraints that most SaaS tools aren't built to satisfy.
- You've already validated with a SaaS tool and you know exactly what you need.This is the best possible position to be in before commissioning a custom build.
- The SaaS pricing at scale is genuinely more expensive than ownership.Do the maths at your projected Year 3 usage. Sometimes custom wins on pure economics.
---
When Buying Is Clearly the Right Call
Similarly, some situations make buying obvious:
- You're pre-revenue or pre-product-market fit. Full stop.
- The function is commodity infrastructure — email, payments, auth, storage, analytics.
- You need it working this quarter, not this year.
- Your team has no in-house engineering capacity and you can't afford to hire properly.
I'd also add: if you're building as a founderto avoid making a harder business decision, that's worth examining. Custom builds can be a very expensive form of procrastination.
---
The Hybrid Play (Often the Smartest Move)
Here's the thing nobody talks about enough: build and buy aren't mutually exclusive.
The most pragmatic approach I've seen work repeatedly is this — buy the commodity pieces aggressively, and build the thin layer of differentiated logic on top. Your CRM is HubSpot. Your support desk is Intercom. But the bespoke workflow engine that connects them and automates your specific process? That's two weeks of custom dev, not six months.
At Seahawk, we've built hundreds of sites on WordPress — a bought platform — with custom plugins that do genuinely novel things. The platform handles the 80%. We build the 20% that matters. It's boring advice. It's also the advice that's worked most often.
---
FAQ
How do I know if my use case is truly unique enough to justify a custom build?
Honest answer: most aren't. Start by spending a serious afternoon — I mean four or five hours, not twenty minutes — mapping every SaaS product in your category. If you've done that and nothing covers your core requirement, ask yourself whether that requirement is actuallynecessary right nowor whether it's a nice-to-have you've elevated into a blocker. If it's truly necessary and truly unserved, that's a signal worth taking seriously.
What's the minimum team you need to responsibly own custom software?
At minimum: one developer who understands the codebase deeply, and either a second developer or a retained agency who can cover when they're unavailable. Owning custom software with a single freelancer and no backup is a fragile position. I've seen it cause real operational damage when that one person becomes unavailable — holiday, illness, a better job offer.
Should I build in-house or hire an agency to build custom?
Depends almost entirely on whether software is your core business. If you're a software company, you almost certainly want in-house eventually, even if you use an agency to get started. If software is a tool that supports your business rather than the business itself, an agency relationship with a proper SLA is usually more cost-effective than hiring engineers full-time.
Is open-source a middle path between building and buying?
Yes, and it's underused. Tools likeMetabasefor analytics, Directus for headless CMS, or ERPNext for operations give you the flexibility of custom software with significantly lower initial build cost. The catch: you're still owning infrastructure and you still need someone technical to manage it. It's not free — it's just cheaper to start.
---
A Final Thought
The build vs buy question doesn't have one answer. It hasyouranswer, specific to your stage, your team, your competitive position, and what you've actually validated so far.
What I'd push back on is the romanticism around building. Custom software is not inherently more serious, more scalable, or more impressive than a well-configured SaaS stack. The invoicing founder I mentioned at the start? He eventually built something genuinely custom — but only after eighteen months of using Invoice Ninja taught him exactly what his customers actually needed. The build was better for the wait.
Start with the boring option. Earn the right to build something new.