Growing a Platform: Breadth, Depth and Gear Shifting

You cannot anticipate every need.

The most expensive misconception in platform engineering is that building a platform in one shot is more efficient than growing it through discovery.

The platform nobody used

I’ve seen large organisations spend well over a year building a cloud platform to “streamline cloud development”, only for it to have no users when it launched. Progressive teams already had their own setups, some found it too prescriptive, and others found it too complex. It was built with no specific user in mind. Trying to make everyone happy, it made no one happy. That’s what skipping the explore phase looks like (Explore, Expand, Extract).

Breadth against depth

• Too broad. “I’d use your platform if you just added feature X.” Chasing every request spreads the platform thin, and those edge users may never adopt it anyway.
• Too deep. Every capability becomes a learning cliff, and cognitive load rises for everyone.
• Spiral upwards. Iterate by adding a little to each part of the platform, or divide and conquer and finish one aspect at a time. Either way, keep moving in small loops.
• Be transparent. Not everyone will like your trade-offs. Publishing the roadmap, and showing the loop is turning, buys goodwill. People can wait for what they need, or join in and help shape it.

A set of curves

Users don’t watch the platform grow from the beginning; they arrive at any point. Someone who joins late meets everything at once, with much higher cognitive load than the people who grew up with it. Look at the platform through a newcomer’s eyes as well as an existing user’s:

• sensible defaults
• templates for a small set of base cases
• docs and training that people can follow on their own (slow to build, worth it)
• tips that lead people towards advanced features when they’re ready

Gear shifting

A simple, low-code path is great for a specific set of users. When their needs outgrow it, let them shift gear: drop down to code and extend. There’s a learning curve at the shift, but it’s far better than halting the people who’ve outgrown the simple path (Low-Code Platforms: Where Do They Belong?).

Friction sets the batch size

When development friction is low, teams take smaller steps and debug more readily. When releases or feedback are slow, they wait, batch up work and suffer painful merges, even though smaller releases would mean fewer conflicts. DORA Metrics make this visible, as long as nobody turns them into targets (Goodhart’s Law).

Slicing and scaling

To grow without big bangs: feature flags, service stacks and composable services. And remember that scaling down is harder than scaling up (SLA vs SLO vs SLI).

Related: Internal Developer Platform · Golden Paths · Web Accelerator · Platform Strategy