Build, buy, or borrow

I don't have a default on this one, and I've stopped pretending to.

The rule everyone quotes, build your core and buy everything else, sounds right and falls apart on contact.

Because the argument is always about what counts as core. Every team believes their thing is core. The billing system feels core to whoever owns billing.

And plenty of companies have built genuinely differentiating things in areas where a rule would have told them to buy.

So instead of a default, three tests.

They take about ten minutes and they resolve most cases without a meeting.

Test one: is this what customers pay us for

Not "is it important." Everything in production is important.

The question is whether a customer would notice, and care, if this part were merely adequate rather than excellent.

If your product is a data platform, the query engine is what they're paying for.

Your authentication isn't. However much of it you've written.

The useful sharpening question.

If a competitor had a better version of this specific thing, would you lose deals over it.

Yes means it's a candidate for building, because you need the ability to make it better than what's available to everybody.

No means buying is the strong default for that piece.

And "ours would be a bit more tailored" isn't a rebuttal. Tailored to what, and worth how much.

Test two: who's on call for it

The test I'd keep if I could only keep one, and it's the same one I use for adopting new technology generally.

Not "can we build it." Get a name.

Building means owning the operational load forever. The upgrades, the incidents, the security patches, the migration in three years, the knowledge concentrated in whoever wrote it.

Can't name the team carrying it at 3am in two years' time? Then you aren't choosing to build. You're choosing to create an orphan on a delay.

It cuts the other way too.

Buying has an owner as well. Somebody manages the relationship, handles the vendor's incidents, which are worse because all you can do is refresh a status page, and is responsible when it fails.

A bought system with no named owner rots exactly like a built one, and the failure is harder to see coming.

So the test isn't build against buy.

Name the person or team for each option. If either name is uncomfortable, that's the real finding.

Test three: what does it cost to get out

Every decision here is a bet on a future you can't see.

So the thing worth pricing is the exit, not the entry.

For buying. What happens if the vendor triples the price, gets acquired by somebody hostile, or simply goes away.

How much of your data model has their concepts baked into it. Could you move in a quarter, or is this a two-year project.

The answer is usually much worse than people assume, because integration depth grows quietly.

For building. What happens if the two people who understand it leave.

How much would have to be rewritten to change one of its core assumptions. Whether anybody outside your company has ever seen this design, which decides whether you can hire for it.

The specific thing to look for is asymmetry.

A decision cheap to reverse deserves ten minutes and a bias toward whichever gets you moving faster today. A decision expensive to reverse in both directions is the one that earns a written document and a real argument.

The exit price isn't fixed, and that's where these go wrong

Both halves above assume you can price the exit today and the number will still be roughly right when you need it.

It won't be. This is the failure mode that catches people who ran the test properly at the time.

A custom API gateway is a defensible build right up until the company starts acquiring.

Then the number of systems that have to pass through it stops being set by engineering and starts being set by corporate development, and every acquisition quietly raises the price of the exit you didn't take.

The original decision never got worse. Somebody reset the variable it was priced against, from a part of the company that wasn't in the room.

The same thing happens on the buy side, from the opposite direction.

Your vendor gets acquired. The product folds into the acquirer's roadmap. And the exit you'd priced at one quarter has stopped being a decision you're making at all.

In AI tooling specifically this has become common enough that it belongs in the test rather than in a risk register nobody reads.

So ask it out loud, in both directions.

What happens to this if the thing underneath it is acquired in the next twelve months.

Ask about the vendor. Ask about your own company. Both answers sit outside your control, and only one of them usually gets considered.

Borrowing, which is the option people forget

Open source, in the middle.

You don't own the roadmap. You do own the operations. And you can read the code when something breaks.

Its real advantage is optionality. You're never held hostage on price, you can fork if you must, and the knowledge transfers because other people have used it.

Its real cost is that "free" software carries an operational bill landing entirely on you, and that bill is frequently larger than the licence you avoided.

The version that goes wrong: adopting an open source project with a small maintainer base for something load-bearing.

Three years later it's unmaintained, you're on an old version with a known vulnerability, and upgrading means adopting a rewrite the maintainer did in year two.

The check is boring and rarely done. How many maintainers. How recent the commits. Who else large is running it in production.

The 80% fit

The most common real situation.

A SaaS product does eighty percent of what you need, and somebody proposes building because of the missing twenty.

Work out what that twenty percent actually is first. It's usually one of three things, and only one of them justifies building.

Sometimes it's a workflow difference, and the honest answer is to change your workflow.

Painful. Cheap. Frequently correct.

Sometimes it's a genuine gap you can close around the edges. A small integration, a script, a thin layer over their API.

Most of these end up here, and it's a good outcome. You get the eighty percent for a licence fee and build only the part that's actually yours.

And sometimes the missing 20% is the thing customers pay you for, in which case the tool was never a candidate for that piece and you've learned something useful about your own product.

The trap is the fourth path.

Buy it, then build so much around it that you now own an integration layer larger than the thing you were avoiding, plus the vendor bill.

That happens gradually. The moment to notice is when a second person starts working full time on the wrapper.

The stage adjustment

Under about twenty engineers, buy nearly everything, and treat the exceptions as genuinely exceptional. You don't have the people to operate what you'd build, and every hour on undifferentiated infrastructure is an hour not spent finding out whether the product works. The cost of a slightly wrong vendor at this size is small; the cost of a distracted quarter is not.

Between twenty and a hundred, the tests above do real work, and this is where most of the expensive mistakes get made. The temptation is that you now have enough engineers to build things, which is not the same as having enough to run them.

Past that, buying gets harder for a different reason: your requirements become genuinely unusual, and the vendor's roadmap starts to matter more than their features. That's the point where building becomes reasonable more often, and where the decision deserves the full written treatment rather than the ten-minute one.