Inner-Platform Effect

A workaround becomes a platform one reasonable special case at a time, until the organization is accidentally maintaining software, or a process, it never intended to own.

2 min read

What Is It?

A pattern first named in software engineering: a system built to be flexible and configurable for a specific unmet need gradually accumulates enough internal customization logic that it ends up recreating, feature by feature, a worse version of the general-purpose platform it was meant to be a lightweight layer on top of. Every special case is individually justified, only the accumulation is irrational. Nobody ever approves “let’s build our own platform,” everyone approves “can we just add one checkbox?” The drift is slow and each individual addition looks reasonable; the accumulated result is a homegrown, under-resourced version of something that already exists, fully built, elsewhere.

Why Does It Matter?

An internal process, spreadsheet system, approval flow, or homegrown tool gets built because an off-the-shelf option didn’t fit an early, genuine need. Each subsequent special case gets bolted on because it’s a small addition to something that already mostly works. Nobody ever decides, explicitly, to build and maintain a full platform, or a full governance process, but that’s what the organization ends up doing, at a fraction of the resourcing a real platform team would have, and without the discipline of an actual product. What actually changes, unnoticed, is ownership: the organization starts out owning a workaround and ends up owning infrastructure, a commitment nobody explicitly accepted. Temporary solutions rarely stay temporary, they either disappear quickly or become infrastructure.

What Changes Once You See It?

You start periodically asking, of any long-lived internal workaround, whether it has quietly grown into something that now competes with a mature, purpose-built alternative, rather than assuming its original justification, “nothing else fit,” still holds.

You also start treating “just one more special case” as a decision worth noticing, since that’s exactly how the drift happens, and once something has clearly become critical, you ask whether it should now become a real product with a proper owner, bought or properly staffed, rather than continuing to be maintained as though it were still a workaround.

Common Misunderstandings

It isn’t a claim that building custom tools is always wrong. Sometimes the need really is unusual enough that no off-the-shelf option fits, and a custom build is the right call.
It doesn’t mean every internal tool is secretly an inner-platform. The pattern specifically describes slow, unnoticed accumulation of general-purpose logic inside something that started narrow.
It isn’t solved by banning workarounds. The fix is a periodic, honest check on what a tool has grown into, not a policy against ever starting one.
It isn’t a failure of the people who built it. Most inner platforms began as exactly the right local solution, the trap is in what happened after.

Diagnostic Question

If we were starting today, would we deliberately choose to build and maintain this ourselves?

Explore Further

Field Notes

None yet.

Related Field Guide

Origin

Popularized by Joe Armstrong, creator of Erlang, in his essay “The Inner Platform Effect” (2006), describing a recurring software anti-pattern in which applications gradually recreate poorly designed versions of general-purpose platforms; widely generalized since to organizational processes beyond software.