At Criteo, the Platform department in R&D provides the set of common technical building blocks used to build all Criteo products and shared services. The main users are all the software engineering and analytics teams across Criteo.
Over the past few years, the Platform teams have made significant strides in enhancing self-service capabilities to improve the developer experience and reduce operational overhead. However, these efforts evolved organically and often in isolation, resulting in a fragmented ecosystem of tools and services that don’t provide the same user experience and vocabulary.
This fragmentation led to several recurring pain points:
- Poor Discoverability: Developers lacked a central place to find Platform offerings, documentation, and support. Awareness depended heavily on internal evangelization, and existing catalogs suffered from limited coverage and outdated information.
- High Cognitive Load: Navigating Platform tools and processes was often complex and time-consuming. Ownership was unclear, making support and incident resolution difficult. Bootstrapping new projects involved many manual steps, discouraging best practices.
- Lack of Unified Observability: Monitoring and debugging required juggling multiple tools and interfaces, with no holistic view of applications and their components.
Such challenges highlight the need for a cohesive Internal Developer Platform (IDP) that could streamline our engineering workflows, reduce cognitive load, and empower developers to ship faster with confidence.
It has been just over a year since we embarked on a journey to build an Internal Developer Platform. This article shares the strategy that enabled the project to gain momentum, discusses the challenges we faced, and reflects on the insights we gained throughout the process.
An IDP is a Full-Time Project
One of the first lessons we learned is that building an IDP is a full-time mission.
While the concept of an IDP may be relatively new, the challenges it addresses are anything but. At Criteo, various teams had already launched targeted initiatives to tackle these pain points: service catalogs, provisioning workflows, platform offering catalogs, etc. Each solved a piece of the puzzle, but none were designed with the holistic vision of an IDP in mind.
The turning point came in 2023, when a group of engineers from different teams used their side-project time to build a Proof of Concept based on Backstage. This initiative wasn’t just a technical experiment but a learning opportunity. It helped us:
- Gain hands-on experience with Backstage
- Identify key challenges like fragmented data, poor metadata quality, and a lack of centralized information
- Validate high-impact scenarios where an IDP could deliver immediate value
After one year, the limits of the Proof of Concept started to show. It became clear that without a dedicated team, the initiative would stall.
Armed with the learnings and a clear articulation of the benefits, we consolidated a strategic document outlining how to implement an IDP based on Backstage that aligned stakeholders across the company. This structured approach was key to securing buy-in and resources. As a result, a new team was formed, with the explicit mission to build, launch, and maintain a production-grade IDP.
Adapt Your IDP to Your Reality
Most IDP frameworks offer a flexible meta-model, but it’s up to you to shape it around your organization’s unique developer workflows, terminology, and architecture. This modeling phase is not just technical, but strategic. It’s your chance to define a consistent vocabulary that helps developers navigate the platform intuitively, without needing to understand the internals of every tool.
We started by identifying the core concepts that matter most to our developers. Here’s how we approached it:
- Applications are the central unit of work. While the term is often overloaded, we deliberately chose a high-level abstraction that hides technical identifiers like service names or product IDs. This makes it easier for developers to focus on what they’re building, not where it lives.
- Resources are supporting components: databases, secrets, repositories, and more. Like applications, their representation in the IDP is intentionally abstracted to shield developers from underlying complexity.
- Teams reflect the many ways developers are organized: permanent teams, virtual teams, guilds, and more. This flexible definition was key to model ownership and collaboration.
Applications and resources are both owned by teams, and applications often depend on resources. These relationships are defined by permissions and access patterns. By abstracting them, we simplify the developer experience and make ownership and dependencies easier to understand and manage.
Actions are how developers interact with the model. They range from how-to documents to automated workflows that modify entities or relationships. Crucially, actions use the same vocabulary as the model, reinforcing consistency and reducing cognitive load.
Scenarios bring everything together. They group relevant parts of the model and actions under a specific context, like debugging or testing. Scenarios are a powerful user-facing layer that helps developers stay focused on their goals, not the tools. They reduce context switching and guide users through complex workflows.
Shared Ownership, Shared Success
One of the most important lessons we learned is that the IDP team cannot, and should not, do it alone.
Platform teams are the subject-matter experts for their domains. They know their clients, their use cases, and their pain points far better than the IDP team ever could. Trying to centralize all that knowledge within the IDP team would not only be inefficient, but it would be impossible.
Instead, we embraced a model of shared responsibility. The IDP team focuses on building the framework and user experience, while platform teams contribute their domain expertise to shape how their entities are represented and interacted with in the IDP.
To make this collaboration concrete, we introduced shared roadmaps, which are living documents co-owned by the IDP team and each platform team. These roadmaps serve as a strategic alignment tool, helping us identify opportunities and guide integration efforts. Each roadmap typically includes:
- Which entities from the platform team should be exposed in the IDP
- How ownership of those entities should be represented
- Which actions should be available to developers
- Holistic UIs that support frequent developer workflows and reduce friction
These roadmaps are reviewed and updated quarterly. Priorities are assigned collaboratively, allowing the IDP team to plan and execute integrations based on real needs and impact.
Building an Internal Developer Platform is more than a technical challenge: it’s a strategic shift. We learned that treating the IDP as a product is essential: it needs a dedicated team, a clear roadmap, and the authority to deliver value.
But structure alone isn’t enough. The IDP must reflect your organization’s reality. Modeling is your chance to speak your developers’ language and simplify their experience through meaningful abstractions.
Equally, success depends on collaboration. Platform teams bring the expertise needed to shape how their domains are represented. Shared roadmaps help align priorities and ensure the IDP evolves with real needs.
These lessons have guided us so far, but they’re not the final word. Our journey is ongoing, and as our organization grows, our understanding of what makes a great IDP will evolve.
