Build vs. Buy: When a Lean Team Should Build Its Own Software (and When It Shouldn't)

The default answer is buy. You should need a real reason to override it — and "we could build that ourselves" is not a real reason.

I want to be upfront about where I'm standing, because it should make you trust this more, not less. I build software for a living. I spent a lot of time building four products from zero, by myself. If anyone has earned the right to be biased toward building, it's me. And the advice I give to almost every operator who asks me whether they should build or buy something is: buy it. Buy it and move on.

That's not false modesty and it's not a setup for a sales pitch. It's the conclusion you reach after you've actually lived on the other side of a build decision — after you've owned the software past implementation, into year two, when the person who built it has left and the requirements have changed and the dependency you picked has gone end-of-life and the whole apparatus is now your problem forever. Building is seductive at the start and grinding at the end. Most build-vs-buy mistakes happen because people weigh the start and forget the end.

So let me give you the framework I use. It's not "buy everything." There are real cases where building is correct, and I'll be specific about them. But the framework starts from a presumption, and the presumption is buy.

Why "we could build that" is a trap

The sentence "we could build that ourselves" is almost always true and almost always irrelevant. Of course you could build it. You have engineers, or you could hire some, or these days you could get a long way with AI assistance. Capability was never the question. The question is what building it costs you over its whole life, measured against what you give up to do it.

The reason the sentence is a trap is that it anchors you on the wrong number. When someone says "we could build that," they're picturing the build — a few weeks, a sprint or two, a working v1 they can demo. That number is real and it is also the smallest number in the entire equation. It's the tip of an iceberg, and the part underwater is where companies drown.

Here's what's under the waterline. There's maintenance — every piece of software rots, dependencies need updating, security holes need patching, the OS underneath shifts and breaks things. There's the bus-factor risk — the person who built it holds the whole mental model, and when they leave, you inherit a black box you now have to reverse-engineer to change. There's opportunity cost, the biggest one and the most invisible: every hour your team spends building and maintaining internal plumbing is an hour they did not spend on the thing your customers pay you for. And there's the upgrade treadmill — the bought tool gets a roadmap, new features, integrations, AI capabilities, all for the price you already pay. Your internal tool gets exactly what you have time to add, which after the first year is usually nothing.

A vendor amortizes all of that across thousands of customers. You amortize it across one: you, or at best a small team. That is the core economic asymmetry of build vs buy, and it is why the default is buy.

The four questions that actually decide it

When an operator asks me to help them think it through, I ask four questions in order. The first "yes" that genuinely lands usually settles it.

1. Is this thing your actual competitive edge?

Not "is it important." Everything feels important. The question is whether this capability is part of why customers choose you over the alternative. If you're a logistics company, your routing optimization might genuinely be your edge — building it could be the right call because being better at it than anyone else is the business. Your payroll system is not your edge. Your internal wiki is not your edge. Your CRM is not your edge. Buy the things that aren't your edge so you have time to build the one thing that is.

The trap here is that operators conflate "core to operations" with "core to differentiation." Payroll is core to operations — if it breaks, people don't get paid. But you are not going to win customers by having a marginally better payroll process than your competitor's, because your competitor bought theirs from the same three vendors you'd buy yours from. Core to operations means buying the reliable one. Core to differentiation means consider building.

2. Does a good off-the-shelf option actually exist?

Sometimes the honest answer is no, and then the calculus changes. There are genuinely underserved niches where every available tool is either built for enterprise and priced accordingly or built for consumers and missing what you need. If you've looked — not "we assumed there wasn't one," but looked — and the market is empty or every option is wrong in the same disqualifying way, building moves from indulgent to defensible.

But be ruthless with yourself about "wrong." A tool that does 80% of what you want and costs $50 a month is almost always a better deal than building the thing that does 100%, because that last 20% is exactly where the maintenance iceberg lives. "It doesn't do it exactly how we do it" is usually an argument for changing how you do it, not for building. Your process is rarely as special as it feels from the inside.

An enterprise company I worked for discovered this the hard way: a "six-week" implementation that consumed the majority of the leadership team and support staff for over six months.

3. Can you afford to own it forever?

This is the question people skip, and it's the one that does the most damage. Building is a forever decision. The moment you ship an internal tool, you've signed up to maintain it for as long as anyone uses it, which is usually much longer than anyone planned. Ask honestly: do you have the engineering capacity to keep this alive in year three, when it's nobody's favorite project, the original author is gone, and it's competing for attention against revenue work? If the honest answer is "we'd build it and then never touch it again," you are not building an asset. You are building a future liability with a working demo attached.

4. What's the cost of being wrong, in each direction?

Buy wrong and you've lost some money and some switching cost; painful, recoverable, and you can usually migrate. Build wrong and you've lost the build time, the maintenance you've already sunk, the opportunity cost of everything you didn't do instead, and you still have to go buy the thing anyway — now from a worse negotiating position because you're behind. The downside is asymmetric. Buying wrong is a bruise. Building wrong is a hole. When the costs of being wrong are that lopsided, the presumption should sit with the cheaper mistake.

The cases where building is actually right

I don't want to strawman building, because there's a real version of it. Here's when I think building genuinely wins.

Build when the capability is your differentiation, per question one — when being better at this specific thing than anyone else is literally the business. Build when you've genuinely searched and the off-the-shelf options are all wrong in the same disqualifying way, and the gap is structural rather than cosmetic. Build when the thing is small, stable, and unlikely to need ongoing change — a thin script that glues two systems together and will run untouched for years is a very different commitment than a product with a UI and users and a roadmap. And build when the cost of a vendor having your data or controlling a capability you can't afford to lose access to, is genuinely existential rather than just uncomfortable.

Notice what's not on that list: "it would be cheaper," "it would be fun," "we'd learn a lot," and "we could do it better." Those are the four reasons that produce most of the regretted builds I've seen. They're all about the start. None of them survive contact with year two.

What AI actually changed about this math

Here's where I must be careful, because there's a fashionable claim going around that AI has flipped the build-vs-buy equation — that since you can now generate working software in an afternoon, you should build everything custom. I build with AI every day, and I think that claim is half right in a way that's dangerous.

What AI genuinely changed: the cost of the build dropped a lot. The tip of the iceberg got smaller. Generating a v1, scaffolding a tool, writing the glue code — all meaningfully cheaper and faster than two years ago. That's real and I won't pretend otherwise.

What AI did not change: the part underwater. AI does not maintain your software for you over three years. It does not hold the institutional context of why this system works the way it does. It does not absorb the opportunity cost of your team's attention. It does not patch the dependency that goes end-of-life or make the architectural call when requirements shift. AI made the cheap part of building cheaper and left the expensive part exactly where it was. So the iceberg didn't shrink the way the hype suggests — it just got more top-heavy, which makes it easier to underestimate, not harder.

The place AI genuinely does move the line is the other side of it. The reason a lot of things used to be reasonable build candidates was that the available products were rigid — you bought the tool and then bent your business around its assumptions, or you built so you could fit your actual process. AI-native products change that, because behavior gets described rather than hard-coded. When a bought tool can be shaped to your process by telling it what you want instead of waiting on a vendor's roadmap, a lot of the old reasons to build evaporate. The honest summary is: AI made building look cheaper while making the best options genuinely more flexible. Both moved. The second one matters more for most operators.

The third option most people miss

Build vs buy is usually framed as binary, and it isn't. The option people skip is "buy from a vendor who builds like an operator" — a tool flexible enough to fit your process without you owning the code underneath. For most of the build candidates I see, that's the actual right answer. You wanted to build because the rigid tools didn't fit. The fix isn't to take on a forever maintenance burden; it's to buy something that bends.

This is the lane I deliberately built in, so take the disclosure for what it's worth. The reason I built four products instead of one is that lean teams kept building the same internal plumbing — gluing a support tool to an HR tool to a docs tool to a training tool because no vendor connected them — and then drowning in the maintenance of it. The point of an operator-built, AI-native suite is to be the buy option that removes the reason you wanted to build, so the cross-product workflow you'd have hand-wired is just there. You get the fit you wanted from building, without signing up to own it forever.

You don't have to buy mine to take the principle: before you build, look hard for the tool that bends. The flexible buy beats the custom build on almost every axis that matters past launch day.

The decision, in one pass

If you're staring at this choice right now, run it straight through:

• Start from buy. Make building earn the override.
• Is it your actual edge? If no, buy. If yes, building is on the table.
• Does a good-enough option exist? If yes, buy the one that fits 80% and adapt the other 20%. If everything's structurally wrong, building is on the table.
• Can you own it forever? If you can't honestly commit to maintaining it in year three, don't build it.
• Which mistake is cheaper? Buying wrong is a bruise. Building wrong is a hole. Bias toward the bruise.
• Before you commit to building, look for the tool that bends. A flexible, operator-built buy option removes most reasons to build.

If after all that you still land on build — genuinely, not because building is more fun than evaluating vendors — then build, and build it well, and budget for the maintenance from day one instead of pretending it's free. That's the honest version of building: eyes open about the part of the iceberg you can't see from the demo.

Closing

The person telling you to buy almost everything is a person who builds software for a living and has felt every part of the iceberg personally. That's not a coincidence. The people most enthusiastic about building tend to be the ones who haven't yet owned a build into its grinding middle years. The people most disciplined about buying are usually the ones who have.

Buy by default. Build when the thing is genuinely your edge, the market is genuinely empty, and you can genuinely own it forever. And when the rigid tools are what's pushing you toward building, look harder for the flexible one before you pick up the shovel. Most of the time, it's already out there, it's cheaper than the hole, and it lets your team spend its hours on the one thing only you can do.