Building a Platform That Doesn’t Suck: Lessons from Scale and Beyond
If you don’t build apps on your own platform, it’s just code. Here’s how to do it right.
A lot of companies think they’re building a platform, but really they’re just exposing internal tools with some APIs. A real platform changes how people build. It’s consistent, extensible, and delightful to use. I’ve built these kinds of platforms inside enterprise companies — and I’ve seen what happens when you don’t.
Platforms have been on my mind for years. I’ve built them, maintained them, and rallied teams around them. In a recent episode of Acquired, Steve Ballmer—yes, the “Developers! Developers! Developers!” guy—was asked what makes a platform. Around the same time, someone asked me how I’d build one today. I’ve done it at scale, where we built an API platform, a UI platform, and an internal developer platform. Here’s what I’ve learned.
Previously at my last job, we built a few platforms: API platform, UI Platform, and a developer platform for internal developers. But before I get into that and share my thoughts, I want to describe what I think a platform is and isn’t.
I believe a platform is something that lets third parties integrate with it, is extensible, and includes at least one killer app or API. Without apps, you don’t have a platform—you just have some code.
In my experience, the best way to build a platform is to start by solving for yourself as if you were a third party, but with the leverage a first party has. For example, if you’re building platform don’t just build without knowing who you’re building for. An easy way to do this is build your own app as a part of it. Something that not only showcases what you can do with the platform, but actually solves a problem people have. Or as YCombinator always says, “Build something people want.”
Once you’ve accomplished this, it’s incredibly easy to showcase the platform and encourage others to build on top of integrate with the platform.
Some thoughts from building platforms
In a previous role, we had hundreds of APIs that looked like they came from a dozen different companies, documentation spread out across 7+ places, no standard for building and shipping, and no consistency. They simply were a bunch of apis put under one roof, but with no direction.
The first thing I did was get all of the people involved into a regular cadence. I used the allegory of the cave as a way to share where we are now and where want to be (the outside world). Weekly we would meet to discuss everything from style of request/responses, date formats, and response times.
Once we came up with a standard, we also brought in teams who worked closest with their API customers. Often referred to as the hackers of the company, they had the most insight into integrating with our APIs and products. More than any other team by a long shot. They were our underdog champions and we learned a lot from them.
Getting buy-in was crucial. I knew I couldn’t just go in swinging a hammer saying, “we’re doing this, or else!” — that simply wouldn’t work. It’s much easier and more fun to get people involved to be a part of the process, so operating transparently and with their feedback is key. Don’t get me wrong, you don’t want to go down the path of bike shedding, so you need a strong opinion and you can’t be dogmatic or have a big ego if you need to change course. If the winds change, you’ll need to change course, but pulling in 17 different directions gets you no where.
When I left we had standardize the APIs to look and feel as if they’re one api coming from one company, had one place for documentation and a style guide, clear ownership over different pieces of the puzzle, and much happier customers. Plus, we implemented a feedback loop that was incredibly insightful and valuable.
🎉 0 to 200
Coining a phrase is something I don’t think you can give yourself credit for, but you can surely buy the domain!
The “0 to 200” method is my approach to measuring developer success. It’s a nod to HTTP 200 (“OK”), the goal of any successful API call. Your platform isn’t working unless a developer can go from zero to their first 200 OK—quickly, reliably, and with minimal friction.
But it doesn’t stop there.
Tracking what doesn’t work is arguably just as if not more valuable. You can learn a lot from what people tell you, but you can also learn a lot from watching what they’re doing, often even more!
Learning that it took 10 steps to complete a routine task means we can improve. Learning where people gave up because they couldn’t get to a 200 OK status is also huge. These insights are so incredibly valuable and often under utilized.
🏗️ How I’d build a platform today (again)
Building a platform isn't just about APIs or abstractions. It’s about enabling others to move faster, with consistency and confidence. I've done this at scale, and here’s how I approach it:
1. Get the Right People in the Room Early
You can’t build a successful platform in a vacuum. Engage stakeholders from engineering, product, security, compliance, support—everyone who either builds on the platform or depends on it. Transparency isn’t optional. Participation drives buy-in.
“If you want people to care about the platform, let them shape it.”
2. Set the Vision
Clarify what you're trying to achieve. “We want to enable X so that Y becomes easier/faster/cheaper/more secure.” A strong vision grounds all decisions. Without it, you’re just building tools.
Anchor in the Value Proposition
Why does this matter? For the business? For developers? Be specific:
Reduce time-to-market
Improve reliability
Simplify onboarding
Enforce consistency
Accelerate compliance
“If your platform doesn't solve real pain, it’s just overhead.”
Audit First, Not Last
Before writing new code, take inventory of what exists. Map systems, services, ownership, dependencies, and known pain points. Then stack-rank by business impact and technical importance. Start where you can win early.
5. Listen to Friction
Feedback is gold—even when it’s noisy. Complaints often mask legitimate patterns. Find the root cause, not just the loudest voice.
“Every 'this sucks' is a potential platform feature waiting to be discovered.”
6. Write it Down: Standards, Not Secrets
Don’t wait for perfection. Document the platform’s intended usage, service standards, API contracts, lifecycle guarantees. People can’t adopt what they don’t understand.
“The best way to find the right answer? Publish a wrong one and listen.”
7. Use It Yourself (Build First-Party Apps)
The best platforms are battle-tested in-house before being scaled outward. Internal usage reveals blind spots, rough edges, and missing features. You earn credibility by dogfooding.
8. Measure & Iterate Relentlessly
Track adoption, usage, support tickets, deployment times, onboarding effort, and DX satisfaction. Measure against two pillars:
Vision (Are we enabling what we set out to?)
Value (Is it actually making life better?)
Developer experience should never be a secondary concern—it’s a core feature.
🍝 SPAGHETTI
I’ve seen how messy this can be inside large orgs. That’s exactly why I love doing it. Embrace the spaghetti! It will be messy. Patterns like the Strangler Fig help you modernize incrementally.
“Spaghetti is opportunity. Every tangled system is a chance to make something better.”
At the end of the day, platforms are about people. Code is the medium, but trust, consistency, and experience are what make it usable. You won’t get everything right the first time—and that’s okay. Just keep shipping value, listening hard, and building for others like you’d want them to build for you.