The CNCF landscape has hundreds of logos, dozens of categories, and no shortage of people telling you what belongs in your platform. Joep Piscaer, Field CTO at Portainer, joined me on Inside Platform Engineering with a take I don’t hear often enough: that the best platform decision is frequently to add nothing at all.
Joep calls the CNCF landscape a candy shop, and it’s a comparison that stuck with me. Just because something’s on the shelf doesn’t mean it belongs in your cart, and the cost of a bad choice doesn’t show up at checkout, it shows up months or years later when someone has to support it.
Watch the episode
You can watch the episode with Joep below.
Inside Platform Engineering with Joep Piscaer
The candy shop problem
Joep’s argument is simple but easy to forget in practice, which is that every tool you add to your platform is a tool you now have to operate, secure, and explain to whoever inherits it. He’s not against new tooling on principle, he’s against choosing it reflexively because it’s popular or well-marketed. His rule of thumb is that the best choice is often no choice at all, and that resisting the landscape is itself a skill worth developing, not a sign you’re falling behind.
Small teams will build lean platforms
One of the more provocative points Joep made was that a platform team with a budget and an SLA will naturally start building for its own survival, not just for its users. His suggested fix leans further than most people may be comfortable with, keep the team small, ideally under eight people (this is very contextual to the organization), so there’s only time for the basics. I liked how he framed a bloated platform as a freight ship rather than a speedboat. Once it’s big, you can only change course by a single degree at a time, no matter how good your intentions are.
Talk to your users before you build
Joep was adamant that understanding why you’re building something matters more than the build itself, going as far as to say a good developer might spend as little as 20% of their time actually writing code. The rest goes into figuring out what’s actually needed. This came up multiple times throughout our conversation. His advice for platform teams is to get out of meetings and sit next to the people doing the work, which he only half-jokingly compared to Fisher-Price’s old “soul-crushing meeting” toy.
Vibe coding is changing who the platform needs to support
We spent time on how AI-assisted coding is reshaping who your platform needs to serve. Joep’s read is that business users are increasingly vibe-coding their own tools because commodity software rarely fits the way their teams actually work. Once they’ve got something that works, they just want a URL, not a ticket in your backlog or a crash course in Kubernetes. What struck me was Joep’s parallel back to Platform Engineering itself. Just as we’re told to go and understand what our users actually need rather than guessing, these business users are doing exactly the same thing for themselves, they just build it rather than ask for it. The job for a platform then becomes hiding all of that complexity so those tools can be deployed simply, while staying lean, secure, and compliant underneath. Whether that’s a threat to platform teams or an opportunity probably depends on how ready your platform already is to support something it didn’t design.
Happy deployments!
Inside Platform Engineering is a series of conversations with Matt Allford and a guest, bringing their own experience and perspective from the world of Platform Engineering.
You can find more episodes on YouTube.
