The Art of Letting Go: Why Your Platform Needs Less Control Than You Think

After nearly two decades building developer platforms, I’ve learned that the moment you truly succeed is when developers find magic in places you didn’t mean to put it.

This is terrifying. It’s also the point.

I’ve been thinking about this a lot lately as I watch the next generation of platforms struggling with how much control to maintain. The instinct is always to constrain, to guide, to protect developers from themselves. We add guardrails, validation, prescribed patterns. We tell ourselves we’re preventing footguns. Really, we’re preventing discovery.

The What-If Spiral

Every platform team I’ve worked with has had the same recurring nightmare: What if developers use our thing wrong? What if they build something we have to support forever? What if they depend on implementation details? What if, what if, what if.

I’ve watched teams spend entire quarters in existential crisis over whether to open-source a simple library. “What if someone finds a bug?” “What if they use it for something we didn’t intend?” “What if someone sees that we did something we’re not proud of?” “What if they fork it and make us look bad?”

The discussion wasn’t really about code. It was about control.

Here’s what these debates miss: open-sourcing isn’t just about letting developers see your code. It’s about signaling trust in them and showing they can trust you. It requires being vulnerable with your audience—letting people into your space where they may do things you don’t like. Even Apple opening the App Store on iPhone was this kind of vulnerability. Notoriously controlling? Yes. But still a step toward openness that fundamentally changed what the platform could become.

Building trust requires giving trust first. There’s no other way.

When Your Database Becomes a Message Queue

At Parse (and later Firebase), we watched developers create cringe-inducing workarounds. People used our database as a message queue. They stored images as base64 strings in fields meant for text. They wrote queries that made our eyes bleed.

Each of these workarounds was a giant neon arrow pointing at where we should improve the product. This is how people wanted to use it.

But there’s a balance. We had customers doing things with our infrastructure that made it much more expensive for us and more difficult to maintain. This led to many healthy but spirited debates with our ops folks! We did ultimately add guardrails, but selectively—to protect the platform for everyone while exploring ways to still give people the tools they needed.

Anthropic’s recent moves to limit usage on Claude Code with Max plans feel like that kind of protective move. But they haven’t been sufficiently transparent about what kinds of things they’re OK with people doing on the platform or how they’re evolving their governance over time (and for what aims). The result? Developers in a giant tizzy, visibly switching away and posting about it on Reddit. The lesson: protection without transparency feels like betrayal.

Signs of Life

Let me be explicit about something: developers using your platform in unexpected ways is a good problem to have.

It means they care enough to push boundaries. It means they see potential you didn’t. It means your platform has escaped your imagination and started living its own life.

The alternative—a platform used exactly as designed and never surprising you—means one of two things: either you’ve built something so constrained that creativity is impossible, or worse, no one cares enough to try.

I’ll take the chaos of unexpected usage over the silence of perfect compliance every single time.

Hyrum’s Law: Lean Into It

If you haven’t encountered Hyrum’s Law, it states: “With a sufficient number of users of an API, it doesn’t matter what you promise in the contract: all observable behaviors of your system will be depended upon by somebody.”

Most platform teams treat this as a cautionary tale. I’ve started seeing it as liberating.

People will depend on your implementation details whether you document them or not. They’ll screen-scrape your UI. They’ll parse your error messages. They’ll time your response latencies and build systems around them. This isn’t a bug in developer behavior—it’s a feature of human creativity.

The question isn’t how to prevent these dependencies. It’s how to evolve your interfaces gracefully and set expectations appropriately with developers so they can develop trust in how you’re going to operate the platform.

The Rules Nobody Wrote Down

This is where most platform teams get stuck. They think the API surface is a technical contract. It’s not. It’s a social one.

Take Java’s undocumented sun.* packages. Can you write code that targets them? Yes. Should you? Well, you’re liable to be broken at any moment if you do. Use at your own risk. Tools still do this, and for good reason—IDEs, instrumentation, and other developer tools often need access to internals. But the contract is fundamentally different from the public API.

Or consider error messages. Can you rely on the exact text? In this era of AI, you might want to surface it directly. But you need to account for the possibility that developers may change the message to make it clearer or more actionable. The social contract says: the error type is stable, the message is not. Even if it’s not written down, we’re all making assumptions like this all over the place. When they don’t align with how the platform owner thinks of it, changes get made that break trust in the platform.

As a platform operator, it behooves you to understand how people are actually using your product. Those unspoken assumptions developers make? They’re not bugs in their thinking—they’re features of your platform’s real interface. Ignore them at your peril. Every time you violate an assumption you didn’t know existed, you burn trust you might not be able to rebuild.

Your real API isn’t what’s in your OpenAPI spec. It’s the shared understanding between you and your developers about what’s stable, what’s experimental, and what’s fair game for creative interpretation. Use this to your advantage. Yes, semantic versioning and deprecation policies are table stakes, but go deeper. Segment your APIs by stability guarantees. Recognize that breaking changes mean different things across artifacts—client library changes hit differently than backend changes (and don’t get me started on how confusing this is going to get with MCP servers in the mix). Be explicit about where things might shift. When developers know which foundations are bedrock and which are quicksand, everyone can move with confidence. Clarity about change enables velocity and trust in the platform.

Why Developers Think You’re Scared

Here’s the thing about constraints: they compound. Every time a developer hits an artificial boundary, they lose a little faith in your platform. Not because the boundary exists, but because it’s arbitrary.

“Why can’t I access that property?” “Why is this method private?” “Why can’t I subclass this?”

Sometimes there are good answers: “If we let you call this, you could leave the system in a bad state that would break assumptions our code needs to run.” That’s a real engineering constraint.

But operating from fear—from anxiety about what might happen—just leaves developers wondering why you’re so afraid.

Here’s the thing: the stuff that scares you is often exactly what excites them.

Scary = Good, Actually

Let’s talk about something scary: Anthropic’s Model Context Protocol (MCP). Yes, developers and users can do very scary things with it. They can give AI systems broad access to tools and data. The potential for misuse is real.

But MCP also opens up a gigantic amount of power for the ecosystem. More capabilities are coming, and we’ll get better at making it safe. The alternative—keeping everything locked down—would have meant missing the entire opportunity.

This is the pattern everywhere. The scary uses are often the innovative ones. The things that make platform teams nervous are exactly the things that make developers excited.

Building Evangelists, Not Just Users

I’ve seen constrained platforms and open platforms. Constrained platforms create satisfied customers. Open platforms create advocates.

Satisfied customers use your product. Advocates build their careers on it. Satisfied customers file support tickets. Advocates answer them in forums. Satisfied customers churn when something better comes along. Advocates migrate their entire companies to your ecosystem.

The difference? Constrained platforms prevent problems. Open platforms enable possibilities.

Where Boundaries Actually Matter

I’m not advocating for chaos. Some boundaries matter. Security boundaries, privacy boundaries, performance boundaries, correctness boundaries—these are real and necessary.

But most of our boundaries aren’t about these things. They’re about aesthetics. About purity. About the anxiety of handing over control and what might happen.

Every time you’re tempted to lock something down, ask: “What would happen if I didn’t?” If the answer isn’t “security breach” or “platform collapse” or “developers would corrupt critical system state,” consider leaving it open. Document it as experimental if you must. Add warnings if it makes you feel better. But leave the door open.

Here’s another test: if there’s functionality that’s useful to you as the platform builder, there’s a decent chance it will also be useful to developers building on your platform—especially those 4p developers extending your ecosystem. The tools you need internally are often the tools they need externally.

The Art of Letting Go

The platforms that defined our industry—Unix, the web, JavaScript, Excel—had terrible vulnerabilities that needed to be deeply thought through and addressed. They hardened over time. But they succeeded because they trusted developers to find value in unexpected places. They treated constraints as last resorts, not first principles.

Now we have something amazing because they were willing to be vulnerable first.

In an era where AI is democratizing development faster than ever, where developers have infinite choices and zero patience for arbitrary limitations, the winning platforms won’t be the ones with the most narrowly-scoped APIs.

They’ll be the ones brave enough to let developers surprise them.

Next time someone on your team suggests locking down an API or hiding an implementation detail, don’t ask “why should we leave it open?”

Ask “why should we close it?”

The answer might surprise you. More importantly, it might surprise your developers. And that surprise—that moment of discovering your platform does more than they expected—that’s where love begins.

And love, not control, is what builds platforms that matter.