Escape hatches allow an open-ended system to absorb many more use cases.

When you add an escape hatch, many use cases go from impossible-no-matter-how-much-effort to possible-with-significant-effort.

But a key danger: now you've taken the pressure off your system, and you forget to add higher leverage ways of doing those newly enabled use cases.

"Simply use the escape hatch!" you say to any new use case.

But use cases that use the escape hatch are a form of debt.

Yes, the creator of the feature was able to accomplish that use case, but their effort doesn't help any other creators with similar use cases.

Each use case has to do a lot of effort on its own.

The escape hatch takes the pressure off and allows you to peek at the actual use cases people have so you can learn from them and prioritize based on usage.

But now you have to sublimate those escape hatch use cases, to make platform improvements to the non-escape-hatch portions, making it easier for creators to make things with less effort.

Code gets stronger when it's exercised, and you want use cases to use the actual platform primitives, not take the path of (individual) least resistance and use the escape hatch.

So make sure to continuously be trying to minimize the number of real-world use cases that must use the escape hatch.

This forces you to constantly improve the platform in ways that will allow even low-motivation creators to create more and more powerful use cases with less and less work.