Chase Roberts, COO at Northflank, challenges the conventional wisdom around internal developer platforms (IDPs), making a compelling case that complexity—not just code—may be your team’s biggest reliability risk.

The Rise and Fall of PaaS

Platform-as-a-Service like Heroku and Cloud Foundry were one of the early examples of platforms focused on developer experience. Developers just wanted to ship workloads without worrying about underlying infrastructure. PaaS solutions made that easy, for a while. But soon, teams outgrew the limited workload types and needed to bring their own cloud infrastructure.

Where PaaS failed, platform engineering stepped in, aiming to support broader workload types and enterprise-scale infrastructure. However, Chase warns that the industry often repeats the same mistakes under a new banner. "An application is not just about ephemeral workloads, it's some combination of services, databases, and scheduled workloads." Platform engineering offers more control, but that control introduces new layers of complexity and trade-offs, especially for reliability.

Internal Developer Platforms Struggle with Complexity and Adoption

Building an Internal Developer Portal today means managing complexity at several layers. However, the tools available to manage that complexity aren’t the best. A lot of teams end up stitching together YAML, Terraform, open-source tools, and tribal knowledge. Even teams that manage to get these systems working still stuggle afterwards with usability. "It takes six months for a developer to get to the point that they can use it because it's so complex."

This complexity doesn’t just slow things down, it undermines reliability. Developers end up bypassing the platform altogether, introducing shadow deployments and inconsistent practices. Chase compares the platform effort to a "forlorn hope," doomed from the start unless it's approached differently. He warns that internal platforms often have brittle codebases only understood by their original authors. When they leave, the whole system risks collapse. "And then we come back to the job to be done, which is the first job is to ship software. And the second job is to make sure that's reliable."

The Build vs Buy Conundrum

Chase brings a product-oriented lens to the classic Build vs Buy platform question: "Does building the platform allow me to charge more for my products?" For most companies, the answer is no. He describes internal platforms as margin-destructive, arguing that every dollar spent on them is a dollar not spent shipping valuable features. "We get to charge more when we ship great features. Any dollar spent on growing the platform... just hurts margins."

He drives the point home with a memorable analogy: companies often behave like bakers who spend all their time building the bakery instead of baking croissants. "At the end of the day, after a year, it still doesn't bake any of the croissants." The focus, Chase argues, should be on outcomes, not on reinventing the wheel. Unless the platform drives revenue, sees wide adoption, and is easy to maintain, teams should consider buying a solution instead.

Workload Portability

Chase challenges one of cloud computing's biggest broken promises: portability. "You go to any engineering leader... and you say, ‘I want my workloads running in the other cloud.’ And they’re like, ‘Oh no, no way.’" Despite Kubernetes’ initial vision of making infrastructure a commodity, Chase says that modern deployments are still bound by the gravity of their original cloud providers. True portability remains elusive.

But there is hope. Chase envisions a new wave of developer platforms that decouple workload logic from infrastructure specifics. "You define your deployment path once and you define it around your workloads and not the infrastructure itself." In this model, deployment becomes consistent across clouds. The result? Organizations regain control, reliability improves, and cloud lock-in begins to break down. "The infrastructure should become a commodity, and it should be the platform layer that enables that."

‍