Reframing "Platform" as "Internal Developer Platform"
The foundations and framework that will guide the platform’s development
The second chapter of the book was initially meant to focus on Platform as a Product, but while I was writing it, I realized that I needed to go deeper into the foundations first. Without that, key ideas would be missing or misplaced. So I decided to rename the chapter to Internal Developer Platform, keeping the “platform as a product” perspective as a section within it. After all, that’s what we’re building throughout the book, and dedicating a chapter to defining it sets the stage properly.
An Internal Developer Platform (IDP) is a curated set of tools, services, and processes that enable development teams to build, deploy, and operate applications efficiently.
More precisely, it brings together the technologies an organization uses into golden paths that reduce cognitive load and enable self-service. I didn’t coin this term. That’s how the industry has referred to this concept for years, and I think the name captures well the essence of what we’re trying to achieve.
You might wonder how an IDP differs from a Platform-as-a-Service (PaaS) like Heroku or Render. The distinction lies in customization and control. A commercial PaaS is a one-size-fits-all solution —you adapt to it. An IDP, instead, is tailored to your organization’s specific needs, technologies, and constraints. You build it, you own it, and you evolve it based on your developers' feedback.
In this chapter, I explain my view of the IDP we’ll be building throughout the book and explore the product mindset necessary to succeed on that journey. Building a platform isn’t just a technical challenge —it’s a cultural and organizational one. The mindset shift is crucial. The platform team doesn’t provide servers, but it enables development teams to do so themselves. The easy path has to be the right path.
One key insight I discuss is the Engineering Momentum Problem. Even a well-designed platform can fail if you underestimate developer inertia. You can’t enforce adoption overnight. Instead, you apply steady, continuous pressure through documentation, support, golden paths, and quick wins, until the platform stops feeling like an imposition and becomes an obvious improvement.
I’m not a product management expert, but I’ve learned a few lessons the hard way. This chapter isn’t a masterclass about it. It’s a collection of practical insights and recommendations that helped me navigate the complexities of building platforms that developers actually want to use.
The chapter also introduces the fundamentals every platform needs: a clear vision, a strategy (including segmentation decisions that are hard to change later), measurable objectives tied to business outcomes, and a flexible roadmap.
I also briefly touch on capabilities, the building blocks of any IDP. We’ll explore them in depth later in dedicated chapters, but for now, think of them as layers or planes: Infrastructure & Resources, Integration & Delivery (CI/CD), Observability, Security & Compliance, and Developer Experience. You don’t build them all on day one. You start with an MVP that addresses your developers’ most pressing pain points and iterate from there.
Speaking of Developer Experience. A platform with excellent capabilities but poor DevEx will struggle to gain adoption. A platform with modest capabilities but great DevEx will thrive. If developers don’t want to use your platform, it doesn’t matter how technically impressive it is.
Finally, I cover metrics. The DORA metrics: deployment frequency, lead time, change failure rate, and mean time to recovery. They are a good starting point.
This chapter sets the foundation for everything that follows. The next chapters will dive into implementation: segmentation, infrastructure, CI/CD, observability, security, and developer portals. Each one builds on the product mindset established here.
As always, I’d love to hear your thoughts. What challenges have you faced when building internal platforms? What worked, and what didn’t? I read you in the comments.
The second chapter will be released as promised in December. I’ll keep you posted.
That’s all for now.
Note: a reminder that you can still get the first two chapters for free if you subscribe to this newsletter today.