The maturity gap in most API strategies
I lead the strategy and delivery of products and systems that solve real problems, support commercial goals and scale across teams and markets. My work spans platform foundations, user-facing experiences, commercial tools and developer products, and I adapt my approach to the needs of each domain. I focus on maturing complex systems, improving the experience for both users and developers and strengthening the foundations that make products reliable, scalable and easy to build on. I care about clarity, good judgement and creating the processes and environments that help teams deliver consistent, long-term impact. My experience covers early-stage, scale-up and enterprise product environments, combining hands-on delivery with team leadership and award-winning work recognised across several innovation competitions.
Most companies have an API strategy.
Far fewer have an API product strategy.
The difference matters more than the words suggest.
On paper, the language is familiar: standardisation, reuse, platform thinking. In practice, the strategy often stalls at the technical layer and never fully matures into something the organisation can execute against.
The gap usually shows up between intent and behaviour.
Teams are encouraged to build APIs, but:
Ownership is fragmented
Standards are optional or inconsistently applied
Success is measured by APIs built, not problems solved
Reuse is hoped for, not designed for
This creates a pattern where APIs exist, but leverage doesn't.
I've seen organisations with 40+ internal APIs, many overlapping in functionality. Teams built what they needed when they needed it. The strategy doc said "reuse and standardization," but there was no mechanism to enforce it, and no one empowered to say "we already have an API for that."
Another sign of immaturity is how change is handled.
Early-stage API strategies optimise for speed. That makes sense initially. But many organisations never graduate from this phase.
APIs remain easy to change long after they become widely depended on. What worked when three teams used an endpoint becomes dangerous when fifteen do, but the governance doesn't evolve to match.
Mature API strategies make a deliberate shift:
From flexibility to stability (fewer changes, more confidence)
From team-level convenience to system-level trust (what's best for the whole, not the part)
From building APIs to managing them (lifecycle, deprecation, evolution)
That shift is less about technology and more about governance, incentives, and accountability.
The hardest part is that maturity requires saying no.
Not every use case should be supported. Not every pattern should be allowed. Not every team should build their own version.
Without these boundaries, APIs accumulate complexity faster than value, and the strategy becomes a collection of one-offs pretending to be a platform.
In my experience, the maturity gap persists because closing it forces uncomfortable conversations:
Who owns this? What standards are non-negotiable? What's the long-term cost of flexibility?
Those conversations feel expensive in the short term. But the alternative, fragmented APIs, duplicated effort, and coordination overhead, is far more expensive. You just pay for it gradually, invisibly, across every team.
APIs don't scale on intent alone.
Maturity shows up in what you're willing to constrain.