Coté

What it actually costs to build your own internal developer platform over five years, and why most “we’ll just build it” pitches are pricing the cheap version.

Sixty people and $7.5 million a year, every year, is what it costs to build and operate your own internal developer platform if you do it the way DIY-minded enterprises end up doing it, and most of the executives signing off don’t see the number, because it’s spread across eight cost centers under “engineering.” The cheap version of the pitch they hear - one team, weekend work, a control plane with a bit of YAML on top - ships v1 and turns into the maintenance burden nobody wants to own. The DIY platform version that actually works is a sixty-person product engineering organization, indefinitely. The numbers below come from a recent Tanzu paper I helped update, so flavor it with a vendor-salt up front if you feel like you need to. But, the staffing structure is concrete enough that anyone who’s run a platform team can pressure-test it.

The weekend project that turned into a 60 person infinite financial commitment

From what I’ve seen, if you align your platform team with something that feels like the CNCF platform reference architecture, you end up with about seven product teams: infrastructure, operations, deployment, runtime and middleware, database, security, and coaching/developer enablement. Each team is one to two pizzas, 4-9 engineers. There’s no personal pan pizzas when it comes to DIY platforms. Share a couple of scrum masters and product owners across the seven. That’s about 60 people total.

At a fully loaded $125k/year per engineer (mid-market US, not Bay Area), you’re at $7.5 million in payroll, every year, indefinitely.

Five years in, you’ve spent $37.5 million on payroll alone for a platform team that, in the success case, is mostly running the thing they built rather than building new capabilities or closing the gap with the vendors who are still shipping.

What “buy” actually staffs to

Enterprises that bought a commercial platform staff to operate it at very different ratios. Some real numbers from public talks and customer conversations¹:

• 30,000 developers supported by 50 platform engineers
• 6,500 developers supported by 16 platform engineers
• 1,200 developers supported by 6 platform engineers
• 350 apps supported by 7 platform engineers

Six to ten engineers covering the same population that, in the DIY case, takes sixty. That sixty is the staffing shape of a real DIY effort because you’re not just running a platform, you’re building it: APIs, integrations, security pipelines, dashboards, upgrade tooling, the next AI capability your developers want, the next compliance regime your auditors want.

In conversations I’ve had with DIY platform organizations over the years, there’s a shadow platform engineering “group.” Each development group tends to have at least one person, if not more, who do the glue work between the DIY platform and what the applications teams do. This is often around build and pipeline integration, security, or just figuring out how to deploy apps and hook-up to services. This staffing cost is completely unaccounted for in the business case spreadsheets.

Why this gets ignored

The visible cost line for a commercial platform is one license number on one PO. The DIY headcount is spread across eight cost centers, charged to “engineering,” and looks like normal hiring. The license number is right there on the page; the DIY total has to be calculated, and nobody runs =SUM on all those people.

Works as designed

Engineers also have a story they tell themselves about building their own platform. Nobody gets promoted for choosing a vendor - the era of not getting fired for choosing IBM was long ago. People get promoted for shipping platforms, and “we shipped a platform built on Kubernetes” is a better promotion-packet line than “we onboarded everyone to a thing we paid for.” This isn’t some moral failing, it’s how engineering organizations and the HR policies that pay them work. The pattern is called résumé-driven development, and it’s well documented:

Extensive RDD-based technology selection may therefore lead to complex or even unmaintainable software consisting of technologies which are not suitable for the requirements, which are unfamiliar to current or future employees, or which did not deliver on their promise and were discontinued. –“Résumé-Driven Development: A Definition and Empirical Characterization,” Jonas Fritzsch, Marvin Wyrich, Justus Bogner, Stefan Wagner, January 2021.

Left behind

The most damaging factor is the velocity gap. When you build your own, the vendors keep shipping; you’re shipping too, but against a moving target. The Tanzu paper puts the gap at 12-18 months within the first couple of years, and the gap widens rather than closes, because the vendor’s team is bigger than yours and their roadmap is funded by every customer they have, not just your one company. The year-three meeting where someone says “we need to add the AI services that Vendor X shipped last quarter” is the meeting where the DIY ROI quietly evaporates.

For the strategy-nerds: comparative advantage, with a 200-year-old assist

The notion of outsourcing non-core infrastructure is older than computers. In 1817, David Ricardo argued that even if you can do something well, you should focus on what you do best and trade for the rest. Portugal could grow grapes and weave cloth, but it specialized in wine and traded for British cloth because that’s where the marginal return was.

If you’re not into early 19th century economics thought leadership, Simon Wardley updated the thought leadership with his much beloved Wardley maps: anything that’s already become a commodity should be bought rather than built, so that your scarce engineering capacity is spent on the parts of the business that actually differentiate you from the competition.

Abby Bangser put this in plain English at KubeCon NA 2025:

It’s not about rebuilding what we can purchase that is available on the market. It’s about making sure we spend our time building the things that are bespoke and important for our organization.

For most organizations, the platform itself isn’t where you differentiate. Your apps are! The platform is plumbing - necessary, valuable plumbing, but plumbing. A useful test: would your customers pick you over a competitor because of your platform? In Dutch grocery, the answer at Albert Heijn and Jumbo is “no” - shoppers care about prices, the app, the checkout, not the orchestrator behind it. At Picnic, the answer is “yes,” but only for one piece - the custom narrow delivery trucks that make their last-mile economics work. Everything else, including the platform, they buy. Knowing which kind of business you are answers the build-vs-buy question for you.

Letting your best engineers spend their careers writing YAML, integrating CI to your registry, and tracking CVEs in container base images is trading down. You’re spending one of the most expensive resources you have, engineering capacity, on something a vendor will take care of for you. The opportunity cost is what you didn’t build with that capacity: the apps that would actually move the business.

What to do about it

Here’s three practical moves for anyone staring at this decision now:

• Calculate the all-in DIY headcount before the meeting. Sixty is the high end; thirty is the low end if you cut corners. Either way, multiply by your fully loaded engineering cost and put the number on the slide. The license-vs-engineers comparison ends most of these debates by itself. Don’t forget to multiply this out in one, three, five, and more years. History shows that the platform will be with you for a long time.
• Be honest about year three. Not v1. Maintenance, integration, and a steady migration debt as your developers ask for things commercial vendors shipped two quarters ago. Look at how frequently AI has been changing and improving over the past two years. Can your DIY platform team adapt that fast to make sure you’re getting those tasty, new AI capabilities?
• Build the developer-facing layer, buy the rest. Portals, golden paths, integrations into your specific business systems are differentiated, so build them. Infrastructure, observability backplane, secrets, certificate management, container registry are commodity, so buy them. The org-design version of the argument is in Platform Engineers Don’t Have Time for Infrastructure; the cycle it fits into is in The Eternal Recurrence of DevOps, and that’s not great for long-term business investment ROI.

Every enterprise that builds its own internal platform is, whether the executives say so or not, choosing to spin up a small platform vendor inside the company. The economics of running a platform vendor are well known and largely punishing. The companies that pick this path should at least know that’s the choice they’re making. Most don’t, because the choice was never made out loud. It was made by inertia, in the meeting where someone said “we’ll just build it ourselves this weekend.”

You should avoid the DIY mess and instead TryTanzu.ai. Or, more bluntly: stop building platforms. Start building apps.

If you’d rather have all of this as a talk, here’s the full version going through all seven pitfalls. Bite-sized videos for each pitfall on cote.io/diy.