At Stripe, I lead the teams that build the Dashboard — the surface every product team ships into. Recently, we achieved what every platform team dreams of: we convinced the organization that building with the core framework is the only way to guarantee quality. Stakeholders started demanding it. Product teams started adopting it.

And immediately, the familiar dissonance set in.

A product team needed a flow the framework didn't have a pattern for yet. So my team stepped in to build a forward-compatible solution, with the intention of later lowering it into the framework.

The result? The product team felt held back. The core framework team felt disempowered and bypassed. And my engineers worried they were writing throwaway code that could be shifted at a whim's notice.

If you've spent any time working in or around platform teams, you know this feeling. It's the daily reality of what leadership usually calls "necessary tension."

I've spent my career building platforms for other people to build on: leading the Node.js project at Joyent, helping build Oracle Cloud Infrastructure, creating Stripe Apps, and now the Stripe Dashboard. And at every single one of them, regardless of the scale or the era, we eventually hit this exact same wall.

To understand why we keep hitting it, we have to zoom out. Because this isn't a modern SaaS problem. It's a pattern that goes back to the very beginning of computing.

Every era of computing has been defined by a single bottleneck. And every major shift has been the moment we figured out how to make that bottleneck essentially free — only to discover the next one waiting behind it. But there's a second pattern running alongside the first: every time we eliminate a bottleneck, we create a platform. The general purpose CPU begat the operating system as a platform for software. Software became a platform for services. Services became a platform for other people's businesses. And each of those platforms eventually faced the same question: are you an accelerant for the people who depend on you, or are you their bottleneck?

When we started, we had to put enormous effort up front just to make a single-purpose machine possible. They were specific. They took up whole rooms to solve one problem, and to make them solve a different problem, you had to rebuild the entire thing. In this era, you were amazed when a new one existed at all. The bottleneck was creating the hardware itself.

But the general purpose CPU changed that. It became the foundation for the operating system — the first platform, a layer that others could build on without having to rebuild the hardware. And the challenge moved from building physical circuits to writing software. Instead of a capital expense spent over years constructing hardware for a single problem, we could now direct humans to write code. But it was a world of shrink-wrapped finality — software programmed onto chips, or pressed onto discs and shipped in boxes. Once it was in the customer's hands, it was done. Getting it wrong wasn't just expensive. It could be fatal to a business. So we spent years in waterfall development, trying to make the software perfect before it shipped.

In this era, the customer could see what should exist. They knew what they needed. But they were waiting for someone else to also see it and spend the capital to get it done. The bottleneck had shifted from creating the hardware to getting the software right.

Then the network abstracted the distribution layer. We were no longer shipping boxes; we were delivering software as a service. It didn't have to be perfect at the start because we could iterate in situ with the customer, giving them exactly what they needed and remaining responsive. The cost of being wrong dropped to nearly zero — mistakes became survivable, not fatal.

This changed the relationship with the customer fundamentally. They were no longer waiting for a finished product in a box. They were a partner in the iteration, co-evolving the software alongside you. And the software itself became a platform — your service was now the foundation on which your customers built their own businesses. The bottleneck had shifted from getting it right to getting it done fast enough.

And then we built out Figma, Jira, IDEs, frameworks, DevOps, databases-as-a-service. All platforms themselves. We gave teams better tools to make them faster at their jobs. Because ultimately, we were bottlenecked on product. We were bottlenecked on design. We were bottlenecked on engineering, producing code. All of these investments — every design system, every PaaS, every deployment pipeline — were incremental improvements around the same fundamental constraint: humans generating the work.

We spent a decade locked in religious wars over which frontend framework or state management library was superior, completely ignoring the fact that the actual speed limit on the industry was how fast a human being could type characters into a text editor. Or perhaps less reductively: how fast a human could translate intent into working software, losing fidelity at every handoff along the way.

The customer, meanwhile, had grown used to co-iteration. But partners get impatient. They could see the potential of what you were building, they expected more of it, and they couldn't understand why it took so long to arrive.

Then comes the transformer.

And with it, this idea that we can produce related tokens far more quickly than we've ever been able to. Those tokens could be written words for PRDs. Those tokens could be visual designs as directed by a human. Or those tokens could be software written to execute to that outcome. Three distinct disciplines — product, design, engineering — normalized into one thing: tokens from an LLM.

We haven't changed the process of how we choose to develop software — we still need humans directing the work. But the cost of producing the output has collapsed to effectively zero. That's not to say the model gets it right on the first pass — neither did we. But when a human directs an agent, each iteration costs cents and seconds instead of days and coordination. You can course-correct in real time. The process hasn't changed. The feedback loop just got orders of magnitude cheaper. And nobody has fully reckoned with what that means.

We're in an even more responsive era than we've ever been. You can watch an agent produce in minutes what used to take a team a sprint. It's as if there's no longer an upper bound on how many people you can hire — except now they work at the speed of inference, not the speed of onboarding.

And then you start thinking about what your job looks like in six months.

If production is free, why does delivery still feel impossible?

If the pattern holds — if every bottleneck, once eliminated, creates a platform — then we should be looking for whatever just became the new bottleneck. It's not producing the code anymore.

If you look at how software actually gets made inside a company — not the technology, but the organizational machinery around it — you'll find a structure we've all built, most of us have complicated feelings about, and almost nobody thinks is working.

You build out an agile environment and you add teams to go build better functionality for your users. But inevitably you end up with too many teams delivering too many features to too many users, and your product starts to be everywhere. Part A doesn't feel like Part B. The customer notices. They lose trust — not because any one feature is bad, but because the inconsistency makes it feel like nobody is in charge, and the product gets harder to use. Conway's law made visible: the customer can see your org chart in your product.

I've lived this at every layer of the stack. At Oracle, we built cloud infrastructure with dozens of teams shipping services in parallel, and the consistency problem hit fast. At Stripe, the question of what it means to feel like "one product" across payments, billing, and issuing is a puzzle we wrestle with daily.

So we do what we've always done: we build a platform. But unlike an operating system or a framework, this one can't be generalized — every company's taste is different. So we staff a team of humans to discover it, encode it, and enforce it. We call them the platform team.

The underlying problem though isn't technical. It's cultural. If every team could independently hold the same bar — if they all understood what everyone else was building and delivered to the same standard — you wouldn't need a platform team at all. Conway's law wouldn't manifest. But humans being humans, that invariant breaks down as the organization scales. So you create a team whose entire job is to be the invariant that the culture can't hold on its own. The platform team sets the bar for consistency — this is what it means to be one of our products, this is what it means to do it our way, this is how to put it together. We ask humans to write the code that codifies our taste, our opinions, our standards — to turn consistency into something enforceable. And we spend the time and capital to make that happen.

But unlike every platform that came before it, this one is made of humans. And humans come with a problem that code doesn't have: they don't want to play custodial services.

And so we hit a cycle that never finds equilibrium. Will the product team wait while the platform team builds what the product needs? Or will we let the product team run as fast as possible and have the platform team come back later to clean it up? Leaders will tell you they "love this tension" or that it's "necessary tension." But in practice, it oscillates.

Endlessly.

The engineers find it demoralizing to clean up someone else's mess, and the company wants to know the ROI. The pitch becomes: customers get consistency, internal teams get simplicity, and we hope the company gets velocity in the long run.

But inevitably, there's a perishable moment. The impatient leader wants to seize the time-sensitive market opportunity. You send the product team out to solve the problem for the customer, because the faster you can get to market, the faster they can take advantage of it, and the sooner you get to solving the next problem for your user. We've built entire architectures, migration strategies, and organizational structures inside our companies just to manage this oscillation. We've institutionalized the tension.

And nobody stops to ask whether the tension itself is the problem.

The platform team — the latest platform in a long line of them — has become the bottleneck.

The customer though, through all of this, is evaluating their options. In the before times, both switching and building it yourself were expensive. You'd have to redirect your own strategic resources away from what mattered most. So you only built it yourself if it was strategic to your own delivery, and you only switched vendors if you could realize the value in a near enough timescale. The friction was real, and it kept you loyal — or at least patient.

But that tension doesn't just exist inside your building. Your entire company is just someone else's platform team.

And now you're in a really strange situation with your customer. They're living the same reality as you are — a world where producing code has zero marginal cost. They know it doesn't cost them anything to potentially replace you. In fact, they're probably still waiting for you to deliver your functionality so they can take advantage of it. You are their bottleneck. And the question has shifted. It's no longer "can we afford to replace them?" It's "can we afford not to?"

Because it's not just about speed anymore. In a world where code is free, your customer can have exactly what they want — built to their spec, on their timeline, without compromising for your platform's opinions or conforming to your roadmap. The cost of switching collapsed. The cost of building it themselves collapsed. And the autonomy that comes with that is something they won't give back.

That doesn't mean companies stop existing. Not every problem reduces to deterministic software — there are still boundaries to the physical world, regulatory relationships, and operational scale that you can't just prompt into existence. But the territory that justifies your existence is shrinking to the things that touch the real world and the advantages you've already earned. Everything else is increasingly up for grabs.

This problem doesn't exist at just one layer. It compounds — fractally — through every layer of the stack. Your internal platform team and your product teams. Your company and your customers. Your customers and their customers. The same tension, that same existential question, recurring at every level of abstraction.

Every platform we've built — from the operating system to the framework to the SaaS product — eventually faced a moment where it had to answer for itself. Am I still making things possible, or am I the thing in the way? The marginal cost of code just went to zero. And now it's the platform team's turn to answer.

The value of a platform team was never really in the code. It was the judgment — the standards, the consistency, the definition of "this is what it means to do it our way." The code was just the incredibly expensive medium through which that judgment was enforced. If the medium is now free, the judgment doesn't disappear. It just needs a different medium.

What if the platform didn't have to be a thick framework that product teams resent? What if it wasn't an expensive team playing custodial services after the fact? If code generation is free, what if the platform becomes a thin veneer? Just a system prompt—a set of constraints and enforceable expectations—that travels with the work itself?

The platform doesn't go away. But what if it stops being a team, and starts being an instruction set?

I'll be honest: I'm not entirely comfortable with that idea. I lead platform teams. I believe in what they do. The people on those teams aren't just enforcing rules — they're making judgment calls, having conversations, building institutional knowledge that's hard to encode. But I also know that the question is coming whether I'm comfortable with it or not. And I'd rather be the one asking it.

Remember that product team that needed a flow the framework didn't have a pattern for? Imagine that same moment, except the agent already knows our constraints, our architecture, our taste. It generates the flow and it's already consistent. My team didn't have to build the forward-compatible solution. The framework team didn't feel bypassed. Nobody argued about what code was throwaway and what was permanent — it just solved the user problem. The tension just... wasn't there.

That's either the future or a fantasy. I'm not sure which yet. But I know which one I'm building toward. And I think you're asking the same question.