Oito apps publicados, uma stack só

Neste post

1. O número exato
2. O que isso dá
3. Velocidade de segunda ordem
4. Um código, duas lojas
5. Aprendizado que acumula
6. Publicação padronizada
7. O que isso tira
8. Teto de performance
9. Dependência de fornecedor
10. Tentação de padronizar demais
11. As três vezes em que quebramos a regra
12. 1. Um jogo em Godot
13. 2. Uma integração em PHP
14. 3. Um app sem back-end nenhum
15. O que não conta como quebrar a regra
16. O que a gente mudaria
17. Onde estamos
18. Resumo

O portfólio da JuxtaLux cobre coisas que não têm nada a ver entre si. Cotação de câmbio e cripto. Perguntas anônimas. Minijogos com ranking. Ponto eletrônico por GPS. Ofertas e cupons. Contagem de calorias. Um chihuahua de jetpack.

Quase todos saíram da mesma stack: Flutter e Firebase.

Este post é sobre o que isso dá, o que tira, e as três vezes em que a regra foi quebrada de propósito.

O número exato

Vale começar pelo que dá para contar. O portfólio inteiro, incluindo o que ainda não foi publicado, tem 22 projetos:

A primeira linha é a stack. A segunda mostra uma coisa que costuma passar batido: Firebase não é a metade da história. Nove projetos não têm Firebase nenhum — jogos que guardam estado no aparelho, um app offline-first, um com back-end próprio. "Flutter e Firebase" é a descrição confortável; a descrição honesta é "Flutter sempre, e o back-end que o problema pedir".

E as categorias não se parecem em nada: sete jogos, cinco de negócios, dois de entretenimento, dois sociais, dois de finanças, além de jurídico, educação, saúde e compras. É essa dispersão que faz a stack única valer — se fossem sete variações do mesmo app, qualquer escolha funcionaria.

O que isso dá

Velocidade de segunda ordem

O primeiro aplicativo é lento de fazer em qualquer stack — o tempo vai para descobrir como publicar, como assinar, como configurar notificação, como estruturar o projeto.

O quinto é rápido, porque autenticação, armazenamento, notificação e publicação já são problemas resolvidos e resolvidos do mesmo jeito.

A palavra que importa é a última. Cinco aplicativos resolvidos de cinco jeitos diferentes não acumulam nada.

Um código, duas lojas

Não é gratuito como a propaganda sugere — há diferenças de comportamento, de política de loja e de ajuste visual. Mas é muito mais barato que manter duas bases, e o custo de manutenção é onde a economia realmente aparece: uma correção, duas lojas.

Aprendizado que acumula

Um problema resolvido em um app aparece resolvido no seguinte. A decisão de moderação do EuRi informou a do Sussurro Secreto. A economia no servidor do CyberDropX informou o desenho do Nebulux.

Isso só acontece porque o terreno é o mesmo. Aprendizado é transferível dentro de uma stack e evapora entre stacks.

Publicação padronizada

Ícone, faixa de tela, assinatura, versionamento, ficha de loja, política de privacidade, página de exclusão de conta. Cada um desses é um pequeno projeto na primeira vez e um script na quinta.

O que isso tira

Teto de performance

Para a maioria dos casos, irrelevante. Para o caso em que importa, importa muito — e aí não adianta discutir com quem já mediu.

Dependência de fornecedor

Firebase é conforto com contrato. Autenticação, banco em tempo real, funções e notificação sem construir nada, em troca de um acoplamento que cresce a cada app.

Trocar depois de oito aplicativos não é uma tarde de trabalho. É oito migrações, cada uma com dados de usuário no meio.

A mitigação possível não é evitar o fornecedor — é não deixar a regra de negócio saber quem ele é. Um repositório entre a lógica e o SDK não elimina o custo de troca, mas o transforma de reescrita em substituição de camada.

Tentação de padronizar demais

O risco real de uma stack única não é técnico, é de produto: começar a resolver todo problema do jeito que a ferramenta prefere, em vez do jeito que o usuário precisa.

O sintoma é reconhecível — todos os aplicativos começam a ter a mesma tela inicial, o mesmo fluxo de cadastro, a mesma navegação. Não porque o problema é o mesmo, mas porque o caminho já estava aberto.

Escolher uma stack é escolher quais problemas você vai ter. Não existe opção sem problema — existe opção com o problema que você prefere.

As três vezes em que quebramos a regra

Uma regra que nunca é quebrada não é uma regra: é uma limitação. Os três casos:

1. Um jogo em Godot

O Troll Quest BR é platformer com fases desenhadas à mão, e o que faltava não era biblioteca de renderização — era editor de cena. O raciocínio completo está em Por que um jogo é Godot.

2. Uma integração em PHP

O coletor de publicações judiciais do Jurislux precisa de endereço estável e tolerância a lentidão, duas coisas que o ambiente serverless não entrega sem contorno. Detalhado em Integração externa: quando a resposta é PHP.

3. Um app sem back-end nenhum

O RodaGrana não tem servidor. Não é ausência de Firebase por descuido: é a constatação de que a conta é local, o dado é do usuário e o servidor só adicionaria dependência. Está em Offline-first com Drift e SQLite.

O padrão dos três é o mesmo: a exceção entra por fronteira, com justificativa escrita, não por preferência do dia.

O que não conta como quebrar a regra

Vale a distinção, porque ela é a diferença entre disciplina e superstição. Usar Riverpod num app e não em outro, acrescentar Flame quando o app é jogo, guardar estado em Hive num caso e em Drift noutro — nada disso quebra a stack. São escolhas dentro do mesmo terreno, e o aprendizado continua transferível.

O que quebra a regra é mudar de terreno: outra linguagem, outro runtime, outro modelo de execução. Foi o que aconteceu três vezes em 22 projetos.

Confundir as duas listas produz os dois erros opostos: ou o time trava em discussões sobre biblioteca como se fossem arquitetura, ou aceita uma linguagem nova achando que é "só mais uma dependência".

O que a gente mudaria

Duas coisas, olhando para trás:

Definir cedo o gatilho de refatoração. O monolito do Nebulux não aconteceu por escolher Flutter; aconteceu por não ter combinado, no começo, qual seria o sinal para reorganizar. Stack única facilita começar rápido, e começar rápido facilita adiar estrutura.

Isolar o fornecedor desde o primeiro app. É barato no começo e caro depois. E a versão barata não é uma camada de abstração completa — é só não chamar o SDK de dentro da regra de negócio.

Onde estamos

Aplicativos publicados no Google Play, a maior parte também na App Store, e uma esteira de projetos em teste fechado. Cada um é laboratório para o próximo, e o blog existe em boa parte para que o aprendizado não fique só no repositório.

Resumo

• O ganho de uma stack única não é o primeiro app: é o quinto.
• Aprendizado acumula dentro de uma stack e evapora entre stacks.
• O custo é teto de performance, acoplamento a fornecedor e tendência a resolver

tudo do jeito da ferramenta.

• Mitigação prática: não chamar o SDK do fornecedor de dentro da regra de

negócio.

• Quebre a regra por fronteira e com justificativa escrita. Três exceções em oito

aplicativos é saudável; zero seria rigidez.

• Combine o gatilho de refatoração no começo, quando ninguém precisa dele.

Perguntas frequentes

Flutter serve para qualquer tipo de app?

Serve para a maioria e não para tudo. Onde ele não é a melhor escolha: jogo com fases desenhadas à mão, que precisa de editor; e qualquer coisa que dependa de recurso de plataforma muito novo, onde a ponte chega depois do nativo.

Dependência de fornecedor é um problema real?

É, e o custo aparece na hora de sair. Firebase é conforto com contrato: você ganha autenticação, banco em tempo real, funções e notificação sem construir nada, e perde a facilidade de trocar. Depois de oito apps, não é uma tarde de trabalho.

Como escolher a primeira stack de um estúdio?

Pelo que você consegue publicar duas vezes. Velocidade do primeiro app importa menos que a do quinto — e a do quinto depende de repetir o mesmo caminho, não de ter escolhido o caminho ótimo.