Okay so I’ve been thinking about this platform engineering conversation, and it’s hitting me that I’ve seen this exact playbook before—in design systems.
And honestly? The parallels are kind of wild. 
Design Systems 101
For those not in the design world, here’s the tldr: Design systems are libraries of pre-built components (buttons, forms, navigation) with consistent patterns (spacing, colors, typography) and sensible defaults (accessibility baked in).
Sound familiar?
Platform engineering is literally design systems for infrastructure.
Design systems provide golden paths for UI. Platform engineering provides golden paths for deployment. Both promise consistency, efficiency, and reduced cognitive load.
Both face the same fundamental tension: How do you balance standardization with innovation?
When the System Becomes a Cage
I learned this the hard way at my failed startup (hi, I talk about this a lot because the lessons are burned into my brain 
).
We adopted a no-code platform to move fast. Basically a “golden path” for product development. It worked great for our MVP—we shipped in weeks instead of months.
But then we needed to build our actual differentiator: A custom workflow engine that made our product 10× better than competitors. And the platform… couldn’t do it.
We had three options:
- Hack around the platform (ugly, unmaintainable)
- Abandon the platform and rebuild from scratch (expensive, slow)
- Ship a compromised version that fit the platform (kills competitive advantage)
We eventually chose option 2. By the time we rebuilt, we’d burned through runway. The golden path became a cage.
The Internal Monopoly Problem
Here’s what makes internal platforms trickier than design systems:
With external design systems (Material Design, Chakra UI, Ant Design), if I don’t like them, I can switch. Market competition keeps them good.
But internal platforms don’t have that forcing function. If your company’s platform team builds something that doesn’t meet your needs, you can’t just switch to a competitor’s platform. You’re stuck with it.
This is why @cto_michelle’s point about treating platform teams like product teams is SO critical. Without market discipline, you need product discipline—measuring customer (developer) satisfaction, iterating based on feedback, treating adoption as a health metric.
What Good Looks Like: Escape Hatches
The best design systems I’ve worked with have what I call “progressive disclosure of complexity”:
- Layer 1 (Golden Path): Pre-built components that handle 80% of needs. Most designers never leave this layer.
- Layer 2 (Customization): Component props and variants for the next 15% of use cases.
- Layer 3 (Escape Hatch): Access to underlying code for the final 5%—the weird, edge-case, competitive-advantage stuff.
Most designers use Layer 1. Power users customize in Layer 2. Innovators build novel experiences in Layer 3.
Does your platform engineering approach have equivalent layers?
Or is it “use our golden path or file a Jira ticket and wait 6 months for the platform team to build it”?
Because if it’s the latter, you’ve recreated the old ops bottleneck with better branding.
The Trust Equation
Here’s what I’ve learned from design systems: Constraints enable creativity, but only if users trust them.
When designers trust that the component library solves their problems better than building from scratch, adoption is organic. They choose it because it lets them focus on hard problems—user experience, innovation, interaction design—instead of reinventing buttons.
When they don’t trust it? They hack around it. They build one-off solutions. They treat the design system like an obstacle rather than an enabler.
This is why adoption metrics matter more than enforcement. If people choose your golden path voluntarily, you’ve built something valuable. If they only use it because it’s mandated, you’ve built a compliance checkbox.
The Question That Keeps Me Up
@eng_director_luis raised this in another thread: At what point does the platform restrict innovation?
Because here’s the thing: Your competitive advantage usually lives in the 20% that doesn’t fit the golden path.
Everyone can build a standard web app. Everyone can deploy a basic API. The stuff that makes your product 10× better than competitors? That’s the weird, custom, off-road stuff.
If your platform optimizes for the 80% use case but makes the differentiating 20% impossible (or prohibitively expensive), have you made a good trade-off?
I don’t have the answer. But I think it’s the most important question in platform engineering.
How to Keep Platform Teams Honest
So here’s my ask for this community: What mechanisms do you use to ensure platform teams stay customer-focused?
Because in my experience, every centralized team eventually drifts toward gatekeeping. Not because people are bad, but because institutional incentives push in that direction. Standardization gets rewarded. Innovation gets seen as risk.
How do you fight that? How do you maintain the balance between golden paths and escape hatches? And how do you prevent the slow drift from “serving developers” to “controlling developers”?
Would love to hear what’s working (or not working) in your organizations. Because I think getting this balance right is the difference between platform engineering as enabling force vs. bureaucratic obstacle.
