Internal Developer Platforms: The Missing Dashboard in Your Data Platform

Why Does Starting a New Data Product Still Take a Week

Large organizations spend millions on modern data platforms and staff them with people who know exactly what they are doing. A data engineer who needs to start a new product on one of those platforms still raises a ticket and waits. In this episode, Konrad Madej explains how internal developer platforms, already established in software engineering, are starting to reach the data world, and what changes for both platform and development teams once developers have a single place to work from.

Watch the episode

Find out how to pick the first use case worth automating, and what a team of three people delivered in three months for one C&F client.

What you’ll hear in this episode

What an internal developer platform is and why data teams adopted the idea later than software engineering teams

How to judge whether the scale of your organization justifies building one

What the thinnest viable platform looks like and how quickly it can start showing results

Why buy-in across teams decides whether these projects succeed

Where the time actually goes

Konrad compares a data platform to a car. Modern cars start with a pedal and a button. Cars from the 1920s required a procedure. A million-dollar data platform can still feel like the second one: powerful, and missing the dashboard that tells a new engineer how to drive it. In practice, starting a new product means raising a ticket for resources and then copying a repository template that some team built well for their own conditions years ago and that nobody has owned since. Then a week of waiting. At ten new data products per quarter, that week adds up to forty weeks a year. Platform teams feel the same pressure from the other side. Once a platform matures, the team that used to build new capabilities ends up working through a queue of requests instead. Konrad is also direct about why the business case is harder to make here. An IDP gives engineering time back to the organization, and internal time savings are more difficult to argue for than new revenue.

Self-service that still has guardrails

Self-service raises an obvious concern for anyone who has watched BI self-service produce hundreds of abandoned reports. The conversation covers how approvals stay in place where they matter, from restricting who can run specific automations to gating actions that commit real spend. Konrad also explains the part of an IDP that gets less attention than automation: the catalog. When a new product is created through the platform, everything created alongside it gets registered, which means the organization finally knows which repository and which infrastructure belong to which product. An annual audit turns into a report. A handover to the DataOps team starts from documented ground.

Thinking about building an internal developer platform for your data teams?

Meet the expert

Konrad Madej

Leader of DevOps Tech Practice, C&F

Konrad has spent two decades in the tech industry, starting as an application developer and growing into the role of software architect. He now leads the DevOps Tech Practice at C&F, where he applies DevOps and MLOps practices to development processes that incorporate machine learning models. His recent work centres on the blueprints and standards that platform teams build on, and on moving repeatable work into automation so that engineers can go back to developing the platform itself. He also has extensive experience managing distributed teams and complex projects in remote environments.

Konrad was previously a guest on C&F Talks, discussing How DevOps Transforms Organizations.

Watch that episode

Let’s connect

Our engineers, consultants, and experts are here to help you uncover solutions tailored to your business needs. Whether you’re looking for targeted support or planning a complex digital transformation, we’re ready to help you achieve more.