Build vs Buy Is Never About Cost

A startup I worked with spent eight months building a custom notification system. Email, SMS, push — the works. Beautiful architecture. Well-tested. Their engineers were proud of it.

They could have used SendGrid and Twilio in a weekend.

That's a build vs buy problem disguised as an engineering project. They couldn't tell the difference between what made their product special and what was just plumbing. So they engineered everything like it mattered equally.

Most build vs buy software frameworks hand you a scoring matrix and tell you to rate things on a scale of one to five. That's not a framework. That's a spreadsheet pretending to be a strategy. The real question is simpler and harder: does this thing deserve your engineering time?

The only question that matters

Every hour your team spends building something is an hour they're not spending on the thing that makes your company different. That's just accounting.

Your engineering time is finite and expensive. A build vs buy decision is really a resource allocation decision. You're not choosing between custom and off-the-shelf. You're choosing what your best people spend their days on.

The framework is one question with two parts. Is this core to what makes your product valuable? And: would a customer choose you over a competitor because of how you do this specific thing?

If the answer to both is yes, build it. If either answer is no, buy it. Everything else is rationalisation.

Where startups get this wrong

The most common mistake isn't building too much or buying too much. It's misidentifying what's core.

Engineers have a natural bias toward building. It's more interesting. You control the outcome. You're not dependent on someone else's roadmap. These are all real advantages, and they're all irrelevant if the thing you're building doesn't differentiate your product.

I've watched teams build custom analytics dashboards when Metabase would have worked. Custom CRMs when HubSpot's free tier covered their needs. Custom auth systems when Auth0 exists specifically so you don't have to think about auth.

The pattern is always the same. Someone says "but our requirements are unique." They almost never are. What's unique is the core product. The infrastructure around it is usually the same stuff every company needs.

Founders make the opposite mistake too. They buy a platform that handles a core business function because building felt risky or slow. Then they spend the next year fighting the platform's limitations, requesting features that never ship, and building workarounds that end up being more complex than a custom build would have been.

Building commodity features wastes engineering time. Buying core features gives away control. Both are expensive. The difference is knowing which is which.

The buy side has hidden costs too

Most build vs buy advice focuses on the risks of building: underestimated timelines, maintenance burden, opportunity cost. All real. But the buy side has its own trap that nobody talks about.

I've seen startups reach month twelve with 20-plus SaaS subscriptions. Monthly tool costs exceeding engineering payroll. Every tool works fine in isolation. Together, they're a mess. Data lives in six different systems, nothing integrates cleanly, and someone's full time job is keeping the Zapier workflows from breaking.

That's not a technology stack. That's a Jenga tower.

The hidden cost of buying isn't the subscription fee. It's the integration tax. Every tool you add is another API to maintain and another vendor's uptime to depend on. Eventually the cost of connecting everything together exceeds the cost of building the thing yourself.

This is where a lot of startup technology strategy breaks down. You optimised for speed early on — buy everything, move fast — and now you've traded one problem for another. You don't have a maintenance burden. You have a vendor management burden. Different flavour, same headache.

A framework that actually works

Forget the scoring matrices. Here's how to make the call.

Start with your unfair advantage. What does your company do that's genuinely hard to replicate? That's your build list. Everything on that list gets your best engineers and your most creative thinking. If you can't articulate your unfair advantage clearly, that's a bigger problem than any build vs buy decision — and worth sorting out before you spend money either way.

Everything else goes on the buy list by default. Authentication. Email. Payments. Monitoring. Analytics (unless analytics IS your product). HR tools. Project management. These are solved problems. Thousands of companies have spent millions building them so you don't have to. Let them.

Watch for the grey zone. Some things feel core but aren't, and some things feel generic but become strategic over time. Your data pipeline might start as a simple ETL job and become the thing that actually makes your product work. Your customer onboarding flow might seem like a standard funnel but turn into the reason customers stay. Revisit the question every six months. The answer changes as your business changes.

Set a review trigger. If your team is spending more than 20% of their time maintaining something you bought, it might be time to build. If you're on your third custom rewrite of something that exists as a mature product, it's time to buy. The first decision doesn't have to be the last one.

The ego trap

Here's the part nobody puts in their framework.

Engineers want to build. It's why they became engineers. Telling a talented developer to integrate someone else's API instead of building something from scratch feels like you're wasting their talent. And sometimes they'll make a compelling technical case for building that's really a case for doing the more interesting work.

That's not a character flaw. It's human nature. But it means every "build" recommendation from your engineering team needs a business sanity check. Not "can we build this better than the vendor?" — almost always yes. But "is building this better than the vendor the best use of our next three months?"

That question lands differently. And it's the question a fractional CTO asks when your team is deep in the weeds and can't see the trade-off from the inside. Your engineers are evaluating the technology. Someone from outside evaluates the decision — whether this is the right thing to spend three months on at all, regardless of how well you'd build it.

Build vs buy is never settled

The companies that get this right don't make the decision once. They revisit it as the business evolves.

What you should buy at ten employees, you might need to build at a hundred. What you built as a scrappy prototype might need to be replaced by a mature platform when reliability becomes non-negotiable. The signals that tell you it's time for technical leadership are often the same signals that a build vs buy decision needs revisiting.

The framework isn't a one-time exercise. It's a habit. Every quarter, look at where your engineering time is going and ask: is this still the right allocation?

The startups that waste the least time are the ones that build only what makes them special — and refuse to feel guilty about buying everything else.