When Buying Beats Building

I spent most of my career building custom software. And I'll tell you something that might surprise you: sometimes buying off the shelf is the right call.

Not because custom software is bad. Because building well takes time, maintenance, and ongoing engineering attention — and not every problem is worth that investment.

The Capability Trap

Teams with strong engineering capability have a specific blind spot: they treat every problem as a build problem. If you can build it, why wouldn't you? You have the skills. You understand your requirements better than any vendor. You won't be locked into someone else's roadmap.

All of that is true. It's also irrelevant when the problem already has a well-solved solution.

Engineering time is finite. Every week spent building an email delivery system, a CRM, a user authentication layer, or a scheduling interface is a week not spent on the thing that actually makes your product worth using. The opportunity cost isn't abstract — it shows up in the features that didn't ship, the product bets that didn't get made, the technical debt that accumulated while the team was busy reinventing something that Stripe or Intercom already solved.

Capability becomes a liability when it's applied to the wrong problems. The question isn't "can we build this?" The answer to that is almost always yes. The question is whether building it is the right use of the engineering capacity you have.

Table Stakes vs Differentiator

The clearest frame for the build-vs-buy decision: is this problem table stakes, or is it a competitive differentiator?

Table stakes are the things every business in your category needs and that customers don't notice unless they're missing. A CRM. Email delivery. User authentication. A booking calendar. Payment processing. File storage. These problems have been solved, expensively and thoroughly, by companies whose entire focus is solving them. Competing with Stripe on payments infrastructure is not a good use of your engineering team's time.

A competitive differentiator is the thing that makes your product better or different from everything else in the market. The specific algorithm, the particular workflow, the data model that reflects how your customers actually work rather than how a generic SaaS assumes they work. That's worth building. That's where custom software earns back its cost.

Applied concretely:

• Your customer data pipeline is probably a differentiator. A CRM to hold the output of it is table stakes.
• Your custom compliance routing logic is a differentiator. The email system that delivers the notifications is table stakes.
• The pricing algorithm that accounts for your specific market dynamics is a differentiator. The booking interface that captures the inputs is table stakes.

The pattern is consistent. Build the logic that reflects your specific understanding of the problem. Buy the infrastructure that surrounds it.

The 80% Test

Most off-the-shelf tools cover 80% of what any given business needs. The gap — the 20% that doesn't fit — is where teams get tangled up.

The question isn't whether the gap exists. It's whether the gap is strategically important.

If the off-the-shelf tool works at 80% and the remaining 20% isn't core to your competitive position, buy it. The custom build will cost more than you think, take longer than you estimate, and create a maintenance obligation that follows you indefinitely. An imperfect SaaS that costs $200/month and adapts to 80% of your needs is usually a better deal than a custom system that costs R600k to build and requires two engineers to maintain.

Where the math shifts: when the 20% gap is the product. When fitting into a vendor's workflow requires compromising on the thing that makes your offering distinctive. When the SaaS constraints are shaping your product decisions rather than the other way around. At that point, the table stakes framing breaks down — you're not paying for a utility, you're building something your competitors can't replicate by signing up for the same tool.

The Hidden Cost of the Wrong Call

Getting this wrong in either direction is expensive, but the costs look different.

Building what you should have bought: you absorb the full engineering cost upfront, then carry ongoing maintenance indefinitely. Every engineer hour spent keeping a homegrown auth system running is an hour not spent on product. The system also tends to lag behind the vendor's offering — you're perpetually rebuilding features that Salesforce or AWS already shipped last year.

Buying what you should have built: you inherit the vendor's constraints. Their data model becomes your data model. Their workflow becomes your workflow. The customisation workarounds accumulate. You spend engineering time fighting the tool rather than building the product. The cost of switching later grows every month you're more deeply integrated.

Both failure modes are recoverable. Neither is cheap. The teams that get this right consistently tend to have a clear answer to one question: what is the thing we build that nobody else can buy?

Build that. Buy everything else.

Armin Marxer writes at zeroclue.dev.