Build vs. Buy Your Kubernetes Development Environment

Every conversation about buying a dev tool now includes a brief silence in which someone mentally scopes building it instead. The instinct isn’t new, engineers have always been one whiteboard session away from replacing any product with a quarterly project. But Claude Code has compressed that quarterly project into a weekend.

And the truth is, with AI, a capable platform engineer probably could build a working prototype in a sprint: something that connects a developer’s code (running on a laptop, in an agent’s sandbox, or in CI) and the remote staging cluster, letting them test against real services without deploying every single time. The mistake is thinking that sprint gets you the finished product. Noting the obvious bias we have as a vendor, here’s what we’ve learned from building and maintaining a Kubernetes development platform: what the other 90% of the work looks like, what it actually costs, and how to decide whether buying or building is the right call.

What is mirrord? #

mirrord is a Kubernetes development platform that lets developers and AI coding agents test code in a production-like environment before deploying it. Traditionally, giving developers a realistic environment to test in means one of two things: spinning up an ephemeral dev/test environment for each of them or having everyone wait their turn to deploy to staging. Both are slow because every iteration means building images and deploying. Ephemeral environments also get expensive fast since you’re duplicating infrastructure for every developer.

mirrord takes a different approach: all developers in the organization share a single staging cluster, and each runs their service wherever they’re working, be it locally on their machine, in a CI runner, or in an agent’s sandbox. mirrord then proxies incoming and outgoing traffic, environment variables, and files between the local process and its counterpart deployed in the cluster. The running service behaves as if it were deployed since it receives real requests and talks to the cluster’s real services, databases, and queues. Because of this, the code behaves as it would in the context of the entire application without actually deploying it. And because everyone shares a cluster that already exists, there’s nothing ephemeral to spin up and no duplicated infrastructure to pay for.

At first glance, building what mirrord does might look like a sprint’s worth of work. A platform engineer can stitch together a proof of concept with kubectl port-forward and some scripting in a week or two: run the new version of a service beside the deployed one, tag requests with a header, and route only the tagged requests to it. The demo works, the new code is testable against real dependencies without deploying it, and paying for a tool starts to feel absurd when your own team just built the core of one in a sprint.

LaunchDarkly wrote about this exact pattern with feature flags: a feature flag is just an if statement, so building a feature management platform looks trivial until you realize that every capability that makes it actually useful turns out to be its own project, requiring you to invest more and more engineering time into it. Our version of “it’s just an if statement” is “it’s just a proxy.” And in both cases, what people miss is that the demo is not the finished product.

The 90% below the waterline #

Here’s what that hidden 90% actually consists of.

Sharing the cluster is the hard part #

We’ve written extensively about the benefits of shared environments over dedicated ephemeral ones in the past, so we’ll assume here that the tool you’re building targets a shared cluster, usually staging, like mirrord does.

The tool has two jobs. The first is letting a developer quickly test their locally running code against that production-like cluster, and this is probably what your proof of concept will cover. The second job is letting every developer do this at the same time, against the same cluster, without stepping on each other. This is where the scope explodes, especially because developers aren’t the only users anymore. With every developer now launching multiple agents and pointing them to the same cluster to verify the code they just generated, a hundred engineers can easily mean several hundred sessions sharing the cluster.

The conflict everyone scopes for is traffic: two developers can’t both receive all the requests hitting a service, so you obviously need HTTP filtering that routes each developer’s requests to the right session, and you could say that part is fairly easy to build as well. What usually goes unscoped is everything else that collides. Two local processes compete for the same queue messages, so you need queue-splitting logic that routes each message to the right session. They write to the same database, so you need a way to give each developer an isolated copy. This is why mirrord has features like queue splitting, database branching, and mirrord Policies that make sharing a cluster among thousands of developers possible. Each is a significant engineering effort on its own, and none of them will be in your v1.

Your R&D org pays the real bill #

Say your five-person platform team spends six months building this. The visible cost is five salaries for six months plus some ongoing maintenance cost, and depending on your budget, that might look fine. But there’s a bigger number. Every day the tool isn’t finished is another day your hundred-person R&D org keeps working with the slow dev loop you set out to fix (here’s how to put a number on what that costs). The meter isn’t just running on the team building the tool, it’s running on everyone waiting for it.

Finished isn’t adopted #

Internal devtools only pay off if engineers actually use them, and the adoption bar is high: the tool should be easy to set up, easy to use, and stable enough that developers trust it with their daily workflow. That trust is hard to earn in the first place because developers don’t rush to try untested internal tools. And it’s even harder to earn back: a developer who tried v1, hit a rough edge, and went back to their old workflow isn’t returning for v2 just because you tell them that things got better. If the experience is clunky, engineers are less likely to file feature requests and more likely to just quietly work around the tool and avoid using it.

This creates an awkward loop for an in-house built tool. You don’t reach that quality bar with just a good design document and a prompt. You reach it by iterating against real developer feedback repeatedly, which means that even after you’re “done” building, you’re not really done. You still need to see what features your team needs that are missing, what parts aren’t stable, and constantly build towards them. But that iteration needs developers actually using the tool, and the rough early versions are exactly what teaches them to stay away. It’s also the stage AI doesn’t really speed up, because the bottleneck is developers hitting friction and telling you about it, not writing the code faster.

Long term support #

The work doesn’t end once the tool is built, because the ground underneath it never stops moving: Kubernetes ships three releases a year, service mesh upgrades can change how traffic flows, and new protocols show up in your stack. Each of these lands on your team as a support request, and each one forces the same choice, either sink more engineering time into the in-house tool or leave the gap unsupported.

What makes this a losing game internally is who you’re doing it for. Every one of those investments serves the same few hundred engineers at your company, so each round of maintenance gets harder to justify against everything else on the platform team’s backlog. That exact same work is easy for us to justify, because a fix or a newly supported protocol ships to tens of thousands of engineers across all the companies using mirrord.

Why vibe coding this isn’t as easy as it seems #

AI has changed the math around the build vs. buy argument: an agent can scaffold a proof of concept in an afternoon instead of a sprint, so building is cheaper than ever. The first half of that is true, and it actually makes the trap worse, because the demo now arrives even faster while the 90% below the waterline still remains a hard problem to solve.

We have some direct experience here. mirrord is a low-level systems tool built in Rust, our engineering team uses AI every day while building it, and we’ve written candidly about how that actually goes. AI is genuinely useful for things like getting oriented in unfamiliar code, exploring approaches, generating scripts to debug things. But all these require the code to already exist. Vibe coding a tool like this from scratch is a totally different experience. With no existing codebase to ground the model in, no domain experts to review the output, and months of sustained work instead of a single scoped session, you’re trusting the model exactly where it’s the weakest: short on context, unsupervised, and running for months.

Even with engineers who know the architecture reviewing every line, and CLAUDE.md files we maintain specifically to feed models that context, we’ve had very few cases of AI shipping a real feature in mirrord without heavy manual intervention.

The TCO comparison #

Here’s what the two options actually cost. The build numbers come from what we’ve seen teams scope once they get past the proof of concept.

A decision checklist #

Questions worth answering with your team before committing either way:

• Can you staff it like a product? Not just 3–5 systems engineers for the six month, but permanent ownership afterward including being on-call and supporting upgrades.
• Does your v1 scope include more than the happy path? If the plan doesn’t mention queue splitting, database isolation, or mesh compatibility, the plan covers only the 10% above the waterline.
• What does an outage cost you? If the answer is “every developer is blocked,” your internal tool needs production-grade reliability from day one.
• Will engineers actually adopt it? If the experience isn’t seamless, engineers work around it, and you end up maintaining a tool nobody uses.
• Does the plan account for AI agents? Coding agents that test their own changes multiply concurrent sessions and need the same isolation guarantees as developers. Scoping for humans only means rebuilding for agents later.
• Do you have a genuinely unusual constraint? Regulatory requirements that no vendor can meet are real reasons to build.

If you answered yes to most of these, building may honestly be the right call for you. For everyone else, the math points the other way.

Where mirrord fits #

mirrord lets developers and AI agents run their code on a laptop, in a CI runner, or in an agent’s sandbox while connected to a real cluster. Incoming traffic, outgoing calls, environment variables, and files all behave as if the process were running inside the cluster, with no image builds or deployments in the loop. And because a mirrord session is just a CLI command, an agent can run the code it just wrote against the real cluster and verify it actually works, instead of guessing or making assumptions.

The shared-environment features that make up the bulk of the iceberg (queue splitting, database branching, traffic filtering) are already built, which is how teams like monday.com and National Australia Bank (NAB) run it for hundreds of engineers against a single shared environment.

But that’s not only what mirrord does. Since this is our main product we’ve built tons of features on top of it:

• Preview Environments: Every pull request spins up a thin preview environment where only the work-in-progress service is duplicated in the cluster as an isolated pod. Reviewers like product managers, QA, or designers get a URL to see real behavior against real services before anything is merged.
• mirrord for CI: The same model applied to pipelines. Your PR’s code runs in the CI runner but is tested against the real cluster, so there’s no ephemeral environment to spin up in CI and no images to build and deploy, which saves teams 20–25 minutes per CI run, with concurrent runs kept isolated from each other and from developers using the same cluster.
• Admin Dashboard: A web interface for the platform team running mirrord, with real-time visibility into mirrord sessions, users, targets, CI pipelines, and adoption trends across the organization. Allows platform teams who buy the tools to show adoption, usage, and ROI to stakeholders.

Whichever way your team decides, price the whole iceberg and not just the part above the water.

Frequently asked build vs. buy questions #