Build vs. Buy: The Decision Founders Get Wrong Most Often

I'm Tom Lang — I've built and scaled engineering organizations for three decades, through multiple acquisitions, and I work as a fractional and interim CTO for growth-stage companies, with particular depth in regulated and integration-heavy environments.

When a founder asks me, "Should we build this or buy it?", they're almost always looking at the sticker price of a SaaS vendor versus the perceived "free" capacity of their salaried engineers. That is the wrong math. The decision is never just about cash — it's about strategic focus and the hidden tax of maintenance.

(This is the forward-looking cousin of replace it or modernize it, which is the build-vs-buy call for a system you already have. This post is about a new capability: do you build it, or buy it?)

Here's how I force teams to evaluate it.

The one axis that actually decides it: core vs. commodity

There is really only one question that dictates this decision: is this capability the exact reason a customer buys your product?

• The core — build it. If you're an AI search startup, you build the retrieval algorithm. It's your competitive moat; you must own the IP and the roadmap. Anything that is genuinely why customers choose you gets built and owned.
• The commodity — buy it. Nobody buys your software because you engineered a bespoke password-reset flow or a custom invoice-PDF generator. You buy Auth0 and Stripe and move on. Undifferentiated plumbing is someone else's product; let it be.

And when you run the numbers, run the real ones. A $2,000-a-month SaaS contract looks expensive right up until you account for the $40,000 of upfront engineering to build the equivalent — plus a perpetual ~15% tax on your team's velocity, forever, just to maintain the thing. That maintenance tax is the cost founders never put in the spreadsheet, and it's usually the number that should have decided the whole question.

The two-directional mistake

Founders get this wrong in both directions, and the symptoms are distinct.

Buying the core — the lock-in trap. A founder white-labels a vendor for the core of their product to get to market faster. The tell shows up a few months later: the roadmap stalls, because every new feature request now depends on waiting for the vendor to update their API. You've outsourced your moat, and you have zero control over your own destiny. Fast today, trapped tomorrow.

Building the plumbing — the ego trap. The team decides to build a custom analytics pipeline, or an internal feature-flag system, or their own auth. This is almost always resume-driven development — engineers have a natural, understandable bias to build, because building is more intellectually stimulating than integrating someone else's boring, reliable tool. Part of my job as a CTO is to be the bad cop here: to force the team onto the off-the-shelf option so they stay focused on the revenue-generating features that are your product.

If I had to say which I see more, it's the ego trap — building the plumbing. It feels like progress, and it's quietly the most expensive mistake on this list.

The scar: a $150,000 billing engine

I once worked with a startup that decided Stripe Billing was "too expensive" at a fraction of a percent per transaction. I think they'd watched one too many videos about how the payment processors overcharge you and how you should build your own. The engineering team convinced the founder they could build a custom recurring-billing engine in a single sprint.

Six months later, the custom system still couldn't handle prorated mid-cycle downgrades, completely failed to calculate international tax, and required a senior engineer working essentially full-time just to manually reconcile failed credit cards. They had burned roughly $150,000 in engineering payroll to save $5,000 in vendor fees — and they'd tied up their best engineer doing a payment processor's job instead of building their actual product. I stepped in, halted the project, and we integrated Stripe in two weeks. Billing was never their moat; it was the definition of commodity, and they'd spent half a year and a senior salary proving it.

The honest goal

So before you build anything, run it through the one question: is this the reason customers buy us? If yes, build it and own it — that's your moat. If no, buy it, integrate it, and get your team back on the work that actually differentiates you — and count the maintenance tax, not just the sticker price. Build your core; buy your plumbing; and be honest with yourself, and your engineers, about which one this really is.

If you're staring at a build-vs-buy decision and your team is itching to build something you suspect you should just buy — or you've already built the plumbing and it's eating your best engineer — that's exactly the call I help founders make. Book a call and we'll sort your core from your commodity.