Every super-app founder eventually faces the same tempting, terrifying idea: let other developers build inside my app. The traffic is mine; the supply can be theirs. The upside is real — WeChat, Alipay, and Grab didn't build every service themselves. But the fear is real too. Open the door and someone ships a scam, a data leak, or a clone of your own feature. Chaos, then scandal, then a regulator.
I've advised on both sides of this. The lesson is dull but durable: openness without a controllable base is just liability with a logo. The base is what decides whether «open» means leverage or exposure.
What "open" actually costs
An open platform's risk isn't the good developers. It's the long tail: a malicious build, an over-permissioned app draining contacts, a payments flow that skims. Apple's App Store and WeChat's mini-program platform both answer this with the same toolkit — review before publish, tiered capability access, and a kill switch. The cost is operational: you run an audit pipeline, a policy team, and monitoring. But that cost is what makes the openness defensible.
The architecture that makes it cheap to govern is the runtime. Instead of letting third parties drop arbitrary native code into your app, you give them a graded API surface inside a sandbox. Sensitive capabilities — payments, contacts, fine-grained location — are gated and require explicit host approval. The package is signed and reviewed before it reaches users. At runtime, the sandbox confines what the code can touch, and the host can pull a non-compliant app from the catalog instantly.
Side by side
| Dimension | "Just let them build" (native) | Open catalog + runtime (host-controlled) |
|---|---|---|
| Entry barrier | Anything goes | Review + graded API |
| Capability access | Full native, risky | Tiered, host-approved |
| Code trust | Unknown | Signed, reviewed package |
| Isolation | None | Sandboxed |
| Takedown | App-store cycle, slow | Host pulls instantly |
| Value capture | Hard to skim | Host sets rules, take rate |
The controllable base is what turns «open» from a threat into a moat. The host defines the catalog — who's in, what they can call, what they pay. Developers get reach they couldn't buy; the host keeps the rulebook, the take rate, and the kill switch. This is the actual structure behind every successful open mini-program ecosystem, and it's why «we'll just open the API» always underestimates the work.
The honest caveat: a runtime doesn't abolish the operational cost of openness. You still need review, policy, and monitoring. What it does is make those controls technically enforceable instead of aspirational — the difference between hoping a bad actor behaves and being able to stop them before users feel it.
If you want the supply without the scandal, the question isn't whether to open. It's whether you have a base that lets you stay in control while you do.
