Todo fundador de super-app enfrenta cedo ou tarde a mesma ideia tentadora e aterrorizante: deixar que outros desenvolvedores construam dentro do meu app. O tráfego é meu; a oferta pode ser deles. O lado positivo é real — WeChat, Alipay e Grab não construíram cada serviço eles mesmos. Mas o medo também é real. Abre a porta e alguém lança uma fraude, um vazamento de dados ou um clone da sua própria função. Caos, depois escândalo, depois um regulador.
Assessorei em ambos os lados. A lição é enfadonha mas duradoura: a abertura sem uma base controlável é só passivo com logo. A base decide se «aberto» significa alavanca ou exposição.
O que «aberto» realmente custa
O risco de uma plataforma aberta não são os bons desenvolvedores. Está na cauda longa: um build malicioso, uma app super-permissiva que drena contatos, um fluxo de pagamentos que desvia fundos. A App Store da Apple e a plataforma de mini-programas da WeChat respondem ambas com o mesmo toolkit — revisão antes de publicar, acesso a capacidades por níveis e um kill switch. O custo é operacional: você roda uma linha de auditoria, um time de política e monitoramento. Mas esse custo é o que torna a abertura defendível.
A arquitetura que torna barato governar é o runtime. Em vez de deixar terceiros soltarem código nativo arbitrário no seu app, você dá a eles uma superfície de API graduada dentro de um sandbox. Capacidades sensíveis — pagamentos, contatos, localização de granularidade fina — são limitadas e exigem aprovação explícita do host. O pacote é assinado e revisado antes de chegar aos usuários. Em runtime, o sandbox confina o que o código pode tocar, e o host pode tirar uma app não conforme do catálogo na hora.
Frente a frente
| Dimensão | «Só deixa eles construir» (nativo) | Catálogo aberto + runtime (do host) |
|---|---|---|
| Barreira de entrada | Tudo vale | Revisão + API graduada |
| Acesso a capacidades | Nativo completo, arriscado | Por níveis, host aprova |
| Confiança de código | Desconhecida | Pacote assinado e revisado |
| Isolamento | Nenhum | Sandbox |
| Baixa | Ciclo de app-store, lento | O host retira na hora |
| Captura de valor | Difícil de skimar | Host fixa regras, take rate |
A base controlável converte «aberto» de ameaça em fosso. O host define o catálogo — quem entra, o que pode chamar, quanto paga. Os desenvolvedores ganham alcance que não poderiam comprar; o host mantém o regramento, o take rate e o kill switch. Esta é a estrutura real por trás de todo ecossistema aberto de mini-programas de sucesso, e é por isso que «só abrimos a API» sempre subestima o trabalho.
A ressalva honesta: um runtime não abole o custo operacional da abertura. Você ainda precisa de revisão, política e monitoramento. O que ele faz é tornar esses controles tecnicamente exequíveis em vez de aspiracionais — a diferença entre esperar que um mau ator se porte bem e poder detê-lo antes de os usuários sentirem.
Se você quer a oferta sem o escândalo, a pergunta não é se abrir. É se você tem uma base que te deixe manter o controle enquanto o faz.
