Build versus buy, a guide for founders

Build or buy is the first real decision a founder makes about software, and it is the one most often made on instinct. This guide replaces the instinct with a method: the questions to ask, the costs to count, and the order to decide in.

Start with buy, always

Set the default to buy and make building earn its place. For the ordinary functions of a business, email, accounting, storage, payroll, a mature product will beat anything you build, because it has absorbed years of edge cases you have not met yet. Building here spends your scarcest resource, engineering time, on a solved problem.

The bar to clear is simple. You build only when buying costs you more than building would, once every hidden cost is counted. Most of this guide is about counting honestly.

The four questions that decide it

Does a real product already do this?

Not almost. A tool that does eighty percent of the job and forces a manual workaround for the rest is often worse than no tool, because the workaround becomes permanent and invisible. Search properly, trial two or three, and be honest about whether the fit is real or hopeful.

Is this function core to how you compete?

Nobody wins by having a slightly better payroll system, so buy it. But the process that is the reason customers choose you, the thing you do differently, is worth owning outright. Off the shelf software makes you work like everyone who uses it, which is exactly what you do not want for the part that sets you apart.

What does the workaround actually cost?

This is the number founders skip. A subscription is visible; the workaround is not. Count the hours your team spends re-keying data between tools, the deals that slip because a step lived in someone's memory, the week it takes to answer a question that should take a minute. Put a real figure on it per month, then per year.

Can you carry the ownership?

A build is a thing you own, which means you maintain it. If you have no one to keep it running and no partner to run it for you, that is a genuine argument to buy, even at a poor fit. Ownership is an asset only if you can hold it.

Run the maths

The decision is a comparison, not a feeling. On one side, the annual cost of buying plus the annual cost of the workaround. On the other, the one time cost of a build plus the smaller cost of running it.

If the workaround alone costs more each year than the build costs once, the build pays for itself inside the first year and every year after is profit. If it does not, keep buying and spend the attention elsewhere. Our post on when to build works through the signals that usually mean the maths has flipped.

Avoid the two expensive mistakes

There are two ways this decision goes wrong, and they cost about the same.

The first is building what you could have bought. A team builds its own version of a solved problem, spends six months and a large sum, and ends up with something less capable than a product it could have rented. The cause is almost always pride or a founder who enjoys building more than deciding.

The second is buying what you should have built. A business forces its core process into a tool that does not fit, pays for it in daily friction for years, and never counts the cost because it never appears on an invoice. This is the more common and more expensive of the two, precisely because it is invisible.

When the answer is build, scope it before you start

If the maths says build, the next mistake to avoid is building the wrong thing well. The failure mode is not bad code, it is a good build pointed at the wrong problem. That is why we start every engagement with a Build Diagnosis: two weeks that turn the hunch into a costed plan, so the build begins pointed at the highest payback and the fee comes off the build if you proceed.

A scoped build is usually smaller than founders expect. The first version does one thing that matters, ships behind real users, and earns the right to grow. The open ended builds that run for a year and never launch are the ones that skipped the decision this guide is about.

The short version

Buy by default. Build only when the workaround costs more than the fix, and only for the parts that set you apart. Count the hidden cost honestly, because it is where the real number hides. And when you do build, decide what to build before you write a line of it. The teams that get this right are not the ones that build the most software. They are the ones that build the least software that matters most.