Graduated Escape Hatch

A platform abstraction is calibrated to the distribution of what teams need, and no calibration serves everyone. The most demanding team is usually the one whose workload justified building the platform, and it is the team most likely to hit a limit.

Without an escape hatch, one missing capability produces total defection: the team builds everything itself, because there is no way to keep the ninety percent that works and replace the ten percent that does not.

Why it matters

Defection is not merely a lost adoption. The defecting team is usually large or unusual, so it now runs a second, divergent stack that the platform team does not support and cannot improve — and its existence legitimises the next defection.

A graduated hatch converts a defection into a customisation, which is supportable.

Implementation patterns

• Three levels, not two: the default in one command · override a specific component while retaining the rest · drop to the underlying primitives while keeping the platform's peripheral services (observability, deployment, identity).
• Make the override a supported path, documented and tested, rather than something teams discover by reading the platform's source. An unsupported hatch is used anyway and breaks silently on the next platform change.
• Record who has overridden what, since that list is both the roadmap for the platform's next capability and the list of teams affected by a change.
• Keep the abstraction inspectable. An abstraction that hides infrastructure until something fails, at which point the team must understand the layer they were told not to think about, has transferred the hardest part of the work to the least prepared moment.
• Treat repeated overrides of the same component as a product signal, and absorb the capability into the default.

Industry example

Multi-product organisations such as Freshworks run product lines with genuinely different requirements — different data residency, different scale, different compliance scope — where the platform built for the largest or oldest product is a poor fit for the others. The response determines whether the organisation ends with one platform or several, and the escape hatch is the mechanism that keeps it one.

Failure scenarios

• No hatch, so a single unmet need produces a parallel stack.
• An all-or-nothing hatch, which is the same thing with extra steps.
• An unsupported hatch, used anyway and broken by the next platform change.
• Overrides untracked, so the platform team cannot assess the impact of a change or see the demand.
• Repeated overrides never absorbed, so the same gap is worked around by every team independently.

Trade-offs

Every escape hatch is a surface the platform must keep working, and a platform with many of them is nearly as complex as no platform at all — while providing weaker guarantees, since the estate is no longer uniform.

The discipline is that a hatch is added on evidence of a legitimate need and closed when the capability is absorbed into the default. The second half almost never happens, which is why the addition bar must be high.

Interview question

"A team says your platform cannot support their database requirement, so they are building their own deployment pipeline too. What has gone wrong, and what would you offer them?"