Build, Buy or Wait Is a Different Call at Each Stage

“If it’s a core business function — do it yourself, no matter what.”
— Joel Spolsky, “In Defense of Not-Invented-Here Syndrome”

Buy by default. Build only where the system is part of why customers choose you. When you cannot yet tell which it is, wait, and put a date on the decision. That is the whole policy. The rest of this post is about why it holds, where it breaks, and how it changes as the company grows.

The reason it needs saying is that most build-versus-buy debates are run as a cost comparison: the vendor’s annual price against some number of engineer-months. The comparison is real, but it is rarely the deciding factor, and the numbers on both sides are usually wrong in the same direction. The build estimate leaves out the cost of running the system for years. The vendor quote leaves out the cost of leaving. A decision made on those two numbers alone is a decision made on incomplete information.

Buy by default

At an early-stage company the scarcest resource is engineering attention, not cash. Every system you build is a system you also run, patch, secure, document and staff when its author leaves. Authentication, billing, email delivery, feature flags, error tracking, CI and support ticketing are not why a customer signs. A competent vendor has already solved the edge cases you have not met yet, and its price is usually below the true cost of the in-house version once the maintenance tail is counted.

That maintenance tail is the part most estimates skip. A full cost model for any feature has a build cost, a running cost, a staffing cost and an eventual cost to retire it, the same structure a proper budget for a product investment uses. Run the comparison on all four and the vendor usually wins for anything outside the core. Martin Fowler made a version of this point years ago with his split between utility and strategic software: utility systems should be bought or kept cheap, and strategic ones deserve your best people. The hard part is not the principle. It is being honest about which bucket a system belongs in.

Engineering teams will often argue the other way, and the argument deserves a fair hearing. Vendors do impose constraints, and a homegrown version can look simpler on a whiteboard. The question to ask is what the simpler version will be missing in a year. Picture a twelve-person seed company where two engineers spend a quarter building an internal feature-flag service because the vendor “does too much.” Twelve months later the service has no audit log, no percentage rollouts and one person who understands it. The quarter came out of the product roadmap, and the company now owns a system that does less than the one it declined to pay for.

Put rough numbers on that hypothetical and the shape is clear. Half an engineer-year to build, then a few weeks a year to keep it working, against a vendor bill that is a small fraction of one salary. Even at double the vendor price, the build takes years to pay back, and by then the company needs the features it skipped.

The burden of proof sits on building.

The case for building, taken seriously

Spolsky’s line at the top of this post is usually quoted as an argument for building, and it is one, but read the whole sentence. His point was about core functions, the ones the business lives or dies on. On those he is right, and the policy above agrees with him. The disagreement is over how much of a company is core. Engineering teams tend to draw that line generously, because building is more interesting than integrating. Leaders tend to draw it too narrowly, because a vendor invoice is easier to approve than a headcount request.

There are honest reasons to build outside the core, and they are worth naming. Vendors raise prices, get acquired, deprecate products and have outages you cannot fix. A workflow can be specific enough that no vendor fits it without heavy customization, and heavy customization on someone else’s platform is a build with extra steps. Internal tooling can also pay back well when it takes repeated manual work off people who should be serving customers, which is the case made in the post on internal tooling as more than a cost center.

So the test is not “never build plumbing.” It is “show the evidence.” If a team wants to build something a vendor sells, ask for three things: the specific capability the vendor lacks, the number of people or customers affected by that gap, and the plan for owning the system after launch. A team that can answer all three has a case. A team that answers with “it would be cleaner” has a preference.

Build where you are different

The default reverses when the system is part of what differentiates the business. A practical test: if you replaced this component with the one your nearest competitor uses, would a customer notice? For the pricing engine at an insurance startup, the matching logic at a marketplace or the ranking model in a search product, the answer is yes. In those places a vendor’s constraints become your product’s constraints, and the vendor’s roadmap quietly becomes yours.

The reverse also holds. Where you have chosen to follow the market rather than lead it, buying is usually the faster and safer route, because the category has already settled what good looks like (the trade-off is covered in innovation versus fast following).

Differentiation also covers data. If a system produces or holds the data that will compound into an advantage, owning its structure matters even when the code is ordinary (see the data moat playbook). Buying the storage is fine. Letting a vendor own the schema and the export terms is a different decision, and it should be made deliberately.

Building the differentiated part does not mean building everything around it. Own the piece that differs, buy the plumbing underneath, and size it to the load you can actually project, the same discipline the Goldilocks approach to platform engineering applies to platforms.

Waiting is a decision, not a delay

Some of these questions arrive before the problem does. A seed company choosing a data warehouse, or debating an internal developer portal, is often solving next year’s problem with this year’s information. Neither building nor buying is right yet, because the shape of the need is unknown.

A disciplined wait has two parts. The first is a cheap stopgap the team expects to discard: a spreadsheet, a scheduled script, a manual step with a named owner. The second is a written trigger that ends the wait, such as the first enterprise prospect that requires single sign-on, or a manual process that consumes more than a day a week. Without the trigger, waiting becomes drift, and the stopgap becomes permanent infrastructure that nobody chose.

Waiting is also the right call when the vendor category itself is immature. If the tools in a space change every few months, an early commitment can cost more to unwind than a short delay costs to absorb. A reversible decision made later is usually worth more than an irreversible one made early, which is the argument against future-proofing applied to vendors. It is also the logic of asymmetric decision-making: keep the downside small and the option open until the information arrives. LLM tooling is the clearest current case, and the same build, buy or wait test applies to it, as this guide to build versus buy for LLM features sets out.

How the call changes by stage

Seed. Buy almost everything outside the core product, and keep the core small. Favor vendors you can leave: standard data formats, an export API, no multi-year commitment. What you are protecting is the ability to change direction.

Series A. The purchased tools start to rub. Integrations multiply, a few vendors no longer fit the workflow, and someone proposes a rebuild. The better answer is usually a thin interface of your own in front of the vendor, so the rest of the codebase depends on your contract rather than theirs. That keeps a future switch inexpensive without paying for a rebuild now, and it is the kind of seam that a SaaS platform built for the long haul needs anyway.

Series B. Every earlier call deserves a formal review, for two reasons. The first is scale. Many vendors price per seat, per event or per gigabyte, and a line item that was immaterial at a few hundred customers can become a margin question at tens of thousands. The point where building becomes cheaper than buying is real, and companies often cross it without noticing. Andreessen Horowitz’s analysis of the cost of cloud at scale is the best-known example: it cites Dropbox reporting $75M in cumulative savings over two years, mostly from moving workloads off public cloud. Few companies operate at that scale, but the arithmetic is the same for smaller line items.

The second reason is that by Series B you know far more about what actually differentiates you. Some purchased systems now sit next to your advantage, and their limits have become product limits. Some systems you built turn out to be ordinary, and the homegrown authentication service or job scheduler is a maintenance cost with no customer benefit. The review should move in both directions: bring a few systems in-house and retire a few homegrown ones in favor of a vendor. Treat the retirements as debt repayment, with an owner and a place on the roadmap, the way technical debt should be managed anyway.

Later stage. The inputs change again. Procurement, security review, data residency and vendor consolidation start to dominate, and the question becomes less “build or buy” than “how many vendors can we afford to govern.” Each vendor is now an access path, a data processor and a line in the security questionnaire, which is why security and access governance belongs in the review alongside cost.

What good and bad look like

A good build-or-buy decision is short and written down. It states whether the system touches differentiation, what building really costs (operating it, not only writing it), what leaving the vendor would cost, and the trigger for revisiting. It names an owner. It is reopened when the trigger fires or when the company moves to a new stage.

A bad decision is made once, by whoever was in the room, and never revisited. It shows up as an engineering team maintaining its own version of a commodity tool, or as a product team telling customers “the vendor doesn’t support that” about a capability that should have been theirs to decide.

The record itself does not need a template. One page, five questions, kept where the next leadership team will find it. What it buys you is the ability to tell, two years later, whether the decision was wrong or the circumstances changed. Those call for different responses, and without a record they look the same.

If you lead technology or product, the question to bring to your next planning cycle is simple: which of our current vendor and build decisions were made at a stage we have already left, and when did anyone last look at them?