The Platform Hierarchy of Needs

Every platform team I’ve talked to wants to build a portal. A slick developer portal with a service catalog, self-service provisioning, and change management workflows. It’s the sexy stuff. It’s also the last thing you should build.

Platforms evolve in layers. Each layer builds on the one below it. Skip a layer and you end up with a portal that provisions services into infrastructure nobody can observe, deployed through pipelines nobody trusts. You’re stacking bricks on sand.

I think about this as a platform hierarchy of needs. Just like Maslow’s hierarchy, you can’t meaningfully work on the higher levels until the lower ones are solid. Here’s what it looks like:

Platform Hierarchy of Needs

At the base you have the fundamentals. Your workloads run in the cloud. Secrets are managed, not hardcoded. Environments are isolated. You have basic APM so you can see when things are broken. Incident management exists as a process, not just someone pinging a Slack channel. Deployments are automated, even if they’re simple. This is the floor. Without this, nothing above it matters.

The next layer up is where things start getting real. Infrastructure as code so you’re not clicking around in consoles. Observability beyond just “is it up?” to actual structured logs, metrics, and traces. Teams own their own incidents instead of throwing everything over the wall to an SRE team. Zero-downtime deployments so shipping code doesn’t mean taking a hit.

Then you mature those foundations. IaC goes from “we have some Terraform” to full coverage with zero clickops. Monitoring becomes proactive instead of reactive. You move from automated deployments to true continuous delivery. And you start showing teams what their infrastructure costs. Not charging them yet, just making the numbers visible. Cost showback changes behavior all by itself.

Once that’s solid, you can start getting sophisticated. Auto-scaling that actually works. Service discovery so services find each other without hardcoded endpoints. Canary and blue-green deployments for safer rollouts. Cost chargeback so teams have real skin in the game on spending.

Higher still, you get traffic shaping, ephemeral environments for testing, and advanced deployment strategies. These are genuinely powerful capabilities. But they’re useless if your teams can’t even see what’s running in production or if your IaC only covers half your infrastructure.

Near the top, platform abstractions and shared libraries let you encode all those lower layers into reusable building blocks. A team spins up a new service and gets observability, deployment pipelines, auto-scaling, and cost tracking for free. This is where the platform really starts compounding.

And finally, at the peak: the portal and change management. Now you have something worth putting a UI in front of. The portal works because every layer beneath it is solid. Change management works because you have the observability, the deployment safety, and the cost visibility to actually understand the impact of changes.

The failure mode is always the same. A team reads a blog post about Backstage, gets excited, and starts building a developer portal when they still have services with no observability and deployments that require SSH access. It’s not that the portal is a bad idea. It’s that it’s a bad idea right now.

Each layer in this hierarchy enables the next one. You can’t do meaningful cost chargeback if you don’t have cost showback first. You can’t do canary deployments if you don’t have zero-downtime deployments figured out. You can’t build useful platform abstractions if the underlying capabilities are half-baked.

The good news is you don’t need to finish each layer perfectly before moving up. You need it solid enough. IaC covering 90% of your infrastructure? Good enough to start thinking about proactive monitoring. Observability in place for your critical services? Start experimenting with canary deployments. It’s not a strict gate, it’s a foundation that needs to bear weight.

Build the base. Stack the bricks. Resist the urge to jump to the top of the pyramid. The portal will be there when you’re ready for it.

Get In Touch.

If you'd like to get in touch, you can reach me at ben@benedmunds.com.


Find me on ...