TL;DR - “Should we build our own platform or buy one?” is the wrong question, and the spreadsheet that answers it is lying to you. It lies by comparing the annual license of the thing you’d buy against a one-time construction estimate for the thing you’d build - as if software you build is a purchase rather than a perpetual staffing commitment. Every platform is already part-built and part-bought; the only decision that matters is where you draw the line. Draw it in one place: buy the undifferentiated substrate, because it is a commodity someone else operates better than you, and build only the thin layer of opinion that is actually yours - the paved roads, the defaults, the glue that encodes how your teams ship. Then fund the built part like a product, forever, not like a project you finish. The teams that get this wrong build the commodity and buy the differentiation, which is exactly backwards.
I build and run platforms for a living, and I have sat in a lot of build-vs-buy meetings. They almost always open the same way: someone shares a screen with a spreadsheet. On the left, a vendor’s annual license - a big, scary, recurring number. On the right, an estimate to build the equivalent in-house - engineer-months times a loaded salary, a single figure with a decimal point that looks precise and therefore trustworthy. The two numbers get compared, a decision gets made, and everyone leaves feeling like adults who did the analysis.
The spreadsheet is lying, and it lies in a specific, predictable way. It prices the buy option at its true recurring cost and the build option at its construction cost only - as if the thing you build gets finished and then costs nothing, the way a house does once the builders leave. Software is not a house. A platform you build is a platform you now operate: patched, integrated, on-call, kept alive against a moving substrate underneath it, staffed by people who could have been building something else. That cost never appears in the “build” cell, which is why “cheaper to build” is the most expensive sentence in engineering.
It’s not build or buy. It’s where you draw the line
Start by throwing out the framing, because “build or buy” is a false binary that no real platform has ever obeyed.
Look at any platform you’d call built-in-house and you’ll find it’s mostly bought. It runs on a cloud you didn’t build, orchestrated by Kubernetes you didn’t write, provisioned with Terraform you didn’t author, watched by a Prometheus you helm installed. The “built” part is exactly what the pillar means when it calls an internal platform a thin layer of opinions over the building blocks your team already uses: a thin seam of your own opinions stretched over an enormous amount of other people’s software. Conversely, any platform you’d call bought still has a pile of your own glue holding it to your identity provider, your billing tags, your naming conventions, your one weird compliance requirement. Nobody buys a platform and uses it untouched. Nobody builds one from sand.
So the honest question is never “build or buy?” It is: for each piece of this platform, which side of the line does it sit on? And there is a right place to draw that line, which the next three sections are about. But first, notice what the spreadsheet did: by forcing the whole platform onto one side, it guaranteed you’d get the composition wrong even if you got the total right. A team that “decides to build” usually ends up building some commodity it should have bought. A team that “decides to buy” usually ends up buying an opinion it should have built. The all-or-nothing framing is how you lose before you’ve priced anything.
The three costs the spreadsheet forgets
Before we place the line, price the build option honestly, because the whole distortion lives in the missing costs. There are three, and they all fall on “build”.
- The maintenance tail. This is the big one and the invisible one. The day you finish building your internal CI system, or your secrets service, or your bespoke deployment controller, you have not delivered a project - you have adopted a dependency that your own team now maintains until it is decommissioned. Upgrades, CVEs, the person who understood it leaving, the feature request that turns into a quarter. Industry estimates for the maintenance share of a software system’s lifetime cost cluster well north of half, often much higher, and none of that is in the build estimate. You didn’t spend the money to build it; you signed up to keep it alive, and that bill arrives every year whether or not anyone opens the spreadsheet again.
- The integration tax on the buy side, and the drift tax on the build side. Buying is not free either, and honest accounting cuts both ways: a bought tool still has to be wired into your world, and that integration is real work the vendor’s price tag doesn’t cover. But the build option carries the worse version of this, which is drift. The commodity underneath your homegrown thing keeps moving - the cloud API changes, the base image goes EOL, the ecosystem standard you forked from moves on without you - and staying current is a permanent tax you pay for the privilege of having written it yourself. Buy the substrate and someone else pays that tax. Build it and it’s yours forever.
- The opportunity cost, which is the only cost that matters. Every engineer-month spent building undifferentiated plumbing is an engineer-month not spent on the thing only your team can do. This is the cost that never makes the spreadsheet because it has no invoice, and it is the one that decides whether the company wins. If your best platform engineers are hand-rolling a secrets store that three vendors sell for the price of a laptop, you are not saving money. You are spending your scarcest resource - senior engineering attention - on a solved problem, and starving the unsolved ones.
Put those three back into the “build” cell and the scary license fee on the left usually stops looking so scary. Which is the point: the spreadsheet wasn’t wrong about the numbers it had. It was wrong about the numbers it left out.
Buy the substrate, build the opinions
Now the line. Here is the whole heuristic, and it fits on a sticky note: buy the substrate, build the opinions.
The substrate is everything undifferentiated - the parts of your platform that look essentially the same at your company as at every other company. Container orchestration. Object storage. A secrets manager. A CI runner. A metrics database. An identity provider. None of these express anything about who you are or how you win; they are commodities, and a commodity is defined by the fact that someone whose entire business is that commodity will always operate it better and cheaper than you will as a side quest. Buy them. This is the boring-stack instinct pointed at your own tooling: don’t build a heavyweight thing to solve a problem the market already solved, and don’t pay the complexity tax of operating it when a vendor will eat that tax for you.
The opinions are the thin, high-value layer that is actually yours: the paved roads, the golden-path templates, the defaults that encode your standards, the glue that makes the bought substrate feel like one platform instead of a pile of tools. This is the part with your fingerprints on it - “at our company, a new service comes with these observability hooks, this pipeline, this compliance baseline, wired in by default.” No vendor sells that, because it’s a statement about you. This is the part worth building, and it is almost always a shockingly thin layer of code and configuration on top of an enormous amount of bought substrate. That thinness is the tell that you’ve drawn the line right.
The failure mode is doing this exactly backwards, and it is astonishingly common: teams build the commodity and buy the differentiation. They hand-roll their own CI engine (commodity, should have bought) and then adopt an off-the-shelf portal that dictates how every team must model a service (differentiation, should have built or left alone). The heuristic that catches it: for each component, ask “would our developers notice if this were swapped for a competitor’s version?” If the answer is no - if a different secrets manager would be a migration and nothing more - it’s substrate, buy it. If the answer is yes, if swapping it would change how people actually work, it’s an opinion, and it’s yours to own. Spend your build budget only where the answer is yes.
This is also the sharpest lens on the developer-portal decision specifically. The framework - Backstage, or a commercial portal - is substrate; the catalogue content and the templates behind it are the opinions. Teams get seduced into building the framework and neglecting the content, which is the line drawn in exactly the wrong place. Buy or adopt the shell, build the paved roads it indexes. The value was never the pane of glass.
Fund it like a product, not a project
There is one more way the spreadsheet lies, and it’s baked into the shape of the meeting itself: it treats the decision as a purchase, a thing you decide once. That framing survives the meeting and becomes how the built platform gets funded - and it’s the reason so many in-house platforms rot.
A platform you build is a product, and products have no finish line. But they get funded like projects: a business case, a headcount allocation, a delivery date, and then - the fatal part - the expectation that once it’s “done”, the team rolls off to the next thing. What actually happens is that the substrate underneath keeps moving, the opinions need to evolve as the org learns, and the paved road silently degrades the moment nobody is tending it. A platform without a standing team isn’t an asset you built. It’s a liability you’re depreciating, and the depreciation shows up as the developers quietly routing around a paved road that no longer paves anything.
So the funding decision that actually matters is not the one-time build-vs-buy number. It is: are we willing to staff this, as a product, indefinitely? If the honest answer is no - if there’s budget to build it but not to run it - then building is off the table regardless of what the spreadsheet says, and buying just moved from “the pricier option” to “the only responsible one”, because at least the vendor’s price includes someone whose job is to keep it alive. This is where build-vs-buy stops being a finance question and becomes an org-design question: you are not deciding what to purchase, you are deciding what your team will be responsible for forever.
And once you’ve built the opinion layer, fund the check on whether it’s working. A platform investment that isn’t moving the metrics that show developers actually shipping faster is a product nobody adopted, and a built platform nobody adopted is the most expensive outcome on the whole board - you paid to construct it and you’ll pay to operate it, in exchange for nothing.
When to just buy, and when to actually build
The honest off-ramps, because “buy the substrate, build the opinions” is a default, not a commandment, and the edges matter.
- Buy the whole thing when you’re small enough that even the opinion layer isn’t yours yet. Below a couple of dozen engineers, your “how we ship” isn’t differentiated - it’s just unformed. A managed platform-as-a-service, or a well-lit path on your cloud provider, gives you a coherent default for a fraction of a single engineer’s time, and you can build your own opinions later, once you actually have some. Building a bespoke platform at this stage is running Kubernetes for three services in a different costume: infrastructure for a scale you don’t have.
- Buy even the opinion-shaped thing when your opinion is “we don’t have one”. If a vendor’s paved road is good enough and you have no strong, differentiating view about how services should be shipped, adopting theirs and inheriting their opinions is a legitimate, often smart, choice. You can always fork later when you develop a real preference. Don’t build a bespoke opinion to express indifference.
- Build the substrate only when you genuinely are the exception. Sometimes your scale, your regulatory position, or your actual product makes a normally-commodity component differentiating - the classic case is the company whose product is the infrastructure. Fine. But the bar is high and the burden of proof is on “build”. “We’re special” is what every team says right before they spend two years rebuilding something they could have licensed. Make the specialness concrete, or buy it.
- Buy when you can’t staff the tail, full stop. This overrides everything above. If you cannot commit a standing team to operate the thing forever, you cannot build it, no matter how cheap the construction estimate looks. An unstaffed in-house platform is worse than a bought one, the same way an unmaintained developer portal is worse than none: it actively misleads people into depending on something that’s rotting.
You earn the right to build a piece of the platform when it’s genuinely yours - when it encodes an opinion that is real, differentiating, and worth a permanent staffing line - and not one component before that.
The bottom line
Build vs buy is the wrong question because it forces an all-or-nothing answer to a decision that is really about composition. Every platform is part-built and part-bought; the skill is drawing the line in the right place. Buy the substrate, because it’s a commodity and someone else will always run it better than you can as a side project. Build the opinions, because they’re the only part that’s actually yours, and they’re a thinner layer than anyone expects. And whatever you decide to build, fund it like the product it is - staffed forever - or don’t build it at all.
So before you put the two numbers side by side, ask the questions the spreadsheet can’t: which of these pieces would our developers notice if we swapped it, and are we willing to run the ones we build for as long as we run the company? Answer those honestly and the build-vs-buy decision mostly makes itself - not as a purchase you optimise, but as a line you draw between the commodity you rent and the opinion you own.
If you’re staring at a build-vs-buy spreadsheet that says build, and something about the “cheaper to build” cell feels too clean - or you’ve built a platform that’s quietly rotting because nobody was funded to keep it alive - that’s exactly the kind of decision I help teams get right. Let’s talk.