The Internal Startup: Winning the Long Game in Platform Engineering

Over the past two-plus years, I’ve dedicated a significant chunk of my time to the ideas behind platform engineering. The more I dug into it, the more it all made sense. While many people I talk to seem to understand the benefits of this next evolution of DevOps, they often miss looking beyond what has become one of the major hypes of the past few years.

It’s not comparable, of course, with the «AI-blabla» currently dominating every conversation – but even there, the connection exists. The mindset behind platform engineering could actually help de-hype AI and refocus us on the actual magic: solving real problems for real people.

Welcome to The Internal Startup, a journey dedicated to transforming platform initiatives from a cost center into a strategic value driver. We need to move way beyond the technical stack to explore the strategy and product mindset required to build a platform that works for the business and that developers actually want to use.

Organizations often treat platform engineering as a technical challenge, but the hardest hurdles are almost always organizational. Too often, platform initiatives become just «another thing we do» rather than the value drivers they could be. To succeed, we must shift our identity. We need to stop acting like «ticket-takers» and start acting like «product owners». We need to treat our internal platform as a startup.

The «Portal Fallacy» and Complexity Theatre

Imagine a platform team that has just finished a six-month marathon. They have built what they believe is the «Ultimate Developer Experience» – a shiny, comprehensive Developer Portal. It has a beautiful UI, a dashboard, and a wizard that helps you click your way to deployment. They launch it with a big presentation, expecting applause.

Instead, they get silence.

The team is baffled. They built exactly what the industry told them to build! But the problem wasn’t the technology; the problem was that they never asked the developers what they actually needed. The developers didn’t want a fancy UI. They didn’t want to leave their IDE to click through a website. They wanted a well-built interface – specifically, a robust CLI that integrated seamlessly into their terminal workflow.

This is what some call Complexity Theatre. The team built what looked impressive (a portal) rather than what solved a customer problem (a CLI). This is the fundamental misunderstanding at the heart of many failed platform initiatives: assuming that «Platform» means «Tooling», when it actually means «Product».

As a father of three children born within just over three years, I find it fascinating to observe how situations change the moment communication enters the room. If you have ever raised a child, this analogy will likely resonate: when they are babies, they cry because they need something, but you have to guess the reason behind the noise – hunger, a wet diaper, fatigue, or boredom. You rotate through assumptions until the crying stops.

But as they grow and start to talk, something deeper happens: they don’t just tell the parents what their problem is; they help them reflect and become better parents. Our developers, however, are already adults. We don’t need to guess, and we don’t need to wait for them to «grow up». Now I know that a company or a team is not a family, but the interaction mechanism is identical: when we communicate openly, the feedback loop doesn’t just improve the outcome – it forces the platform team to reflect, grow, and move more effectively toward becoming the value catalysator it can be.

So… Stop assuming! Start talking to your Devs! Because if the Portal Fallacy is the symptom, the lack of a Product Mindset is the disease. To cure it, we need a new kind of leader.

Stop Taking Tickets, Start Owning Products

An internal startup doesn’t just «build stuff»; it actively empowers the organization to move faster. The key to this shift at Puzzle is a dedicated product role: the Platform Product Lead (PPL).

The PPL focuses on outcomes, not outputs. While a traditional lead might say, «Build a Service Catalog», and the team immediately installs Backstage, the Product Mindset starts with a Problem Statement:

«Locating service owners and documentation is currently difficult, creating a critical risk for the services we operate for our customers. We need to reduce the time to find a service owner from 30 minutes to 2 minutes.»

Instead of dictating the solution, the PPL defines how success will be measured and delegates the problem to the team. This is where the culture shifts. I’d recommend any engineer to talk to actual consumers every now and then. Ask questions. Understand what they truly expect.

Don’t just close tickets; open conversations. Stop acting like a service desk and start acting like a startup founder.

De-Risking the Build: Discovery vs. Delivery

The natural instinct for an engineering team with a fresh budget is to immediately open the IDE, spin up a Kubernetes cluster, and start writing Terraform modules. In the startup world, this is exactly how you burn through your seed funding. You build a product that functions perfectly, scales infinitely, and solves a problem that nobody actually has. You enter the Build Trap.

Most platform teams today operate as Feature Factories, measuring success by the number of tickets closed or features shipped (Output). To avoid this, successful platform teams must operate on two parallel tracks, as famously advocated by Marty Cagan:

1. Product Discovery (The Problem & Solution Space): This is where we separate good ideas from bad ones. We don’t ask «How do we build this?» but rather «Should we build this?» and «Will it actually solve the problem?» This track is about rapid learning and validation – navigating the risks of value, usability, and feasibility before a single line of production code is written.
2. Product Delivery (The Execution Space): Once we have validated that a solution actually works for our developers, we move to delivery. This is where we build the selected solution securely, reliably, and at scale. It’s about high-quality implementation of a proven idea.

As consultants, we often see organizations skip the Discovery track because it feels «slower» than coding. They want to see progress in the form of commits. But nothing is slower than building something that has to be scrapped six months later because it solved the wrong problem.

The PPL acts as the guardian of the «Why», forcing the team to stay in the Problem Space until the pain is truly understood. But while Cagan’s framework gives us the theory, my time on the ice taught me the reality of long-term endurance versus short-term wins.

Short-term Success vs. Long-term Progress: The Hockey Analogy

I argue that changing how the platform team thinks can be the first domino in a much larger cultural shift. Because the platform team sits at the intersection of development, operations, and security, their mindset is contagious.

I was lucky enough to transform my childhood hobby, ice hockey, from a passion into a profession. For 13 years, I played professional hockey in Switzerland and was part of many different organizations. Depending on the leadership, the goal ranged from measuring success based on winning or losing a single game, to winning a championship, all the way to «getting better as an organization every year so that in three years we are among the top four teams in the league».

Every approach is interesting, and some provide a quick rush, but only one is sustainable. Platform engineering is similar. It isn’t just about shipping a tool; it is a continuous process of getting better and shifting a culture toward problem-solving and value creation.

It is the difference between winning a game and building a dynasty. When you stop asking «What tool do you want?» and start asking «What is blocking your flow?», you shift the focus from being busy to being effective.

Sovereignty isn’t Bought, It’s Built

Since 2025, «Digital Sovereignty» has emerged as the defining buzzword of the industry. But for many modern enterprises, it is far more than a trend – it is a survival strategy. To be truly sovereign, a company must be able to control its own destiny, regardless of vendor roadmaps or cloud provider price hikes.

However, sovereignty doesn’t start with a vendor calling their product «sovereign». It starts with an internal mindset leaning toward sovereignty. It isn’t just about where your data sits; it’s about your internal capability.

• Tooling alone is not sovereignty. Owning the code is useless if you don’t have the capability to adapt it.
• True sovereignty is a combination of robust tooling and a product mindset.

A sovereign organization needs a platform that is flexible enough to pivot and a team that is empowered to solve internal problems autonomously. Without the «Internal Startup» mindset, sovereignty becomes a burden of maintenance. With it, sovereignty becomes a competitive engine. Don’t buy your independence – build the capability to keep it.

The C-Suite Translation: From Kubernetes to ROI

You can only do so much with the budget you have. You might have the right mindset and the right PPL, but if you can’t secure resources, the initiative dies. To get management buy-in, you have to stop talking about Kubernetes and start talking their language.

1. Speak the Language of Value: Technical metrics like uptime don’t excite the C-suite. We need to translate «Internal Platform» into «Business Value». Instead of asking for money to install Backstage, pitch it as reducing the Mean Time to Recovery (MTTR) for customer-facing apps.
2. Go Beyond Internal Users: Developers are a means to an end. The ultimate goal is the End User. If a robust platform allows developers to deploy 20% faster, features reach paying customers 20% faster. That is the only metric the business truly cares about.
3. Prioritize Adoption Over Vanity Metrics: Success isn’t «Did you ship the tool?» Success is «Are people choosing to use it?»

If you want the budget, stop selling infrastructure and start selling speed, safety, and sovereignty.

Conclusion

Building a platform is easy; building a platform that people actually use and that strengthens the organization, is hard.

By treating your platform team as an internal startup, you don’t just improve your Developer Experience. You begin to transform the entire IT culture into a problem-solving machine and build the foundation for true digital sovereignty.

Start by identifying your Platform Product Lead. Move from the Solution Space back into the Problem Space. Stop building for someone, start building with someone.