Modernização mobile e arquitetura-alvo
Apoio plataformas brownfield e críticas (Super Apps, Server-Driven UI, modularização) com GenAI como alavanca, não como atalho que deixa dívida escondida. A saída é uma rota de migração que pode ser interrompida a qualquer passo.
Arquitetura de Super App com aplicação hospedeira e cerca de 20 mini apps.
Para quem é
- Aplicativos maduros em produção onde cada nova feature custa mais que a anterior e o time já não consegue explicar por quê
- Plataformas com múltiplos times disputando o mesmo código, onde uma mudança em um módulo quebra outro sem aviso
- Empresas avaliando Super App, mini apps ou Server-Driven UI, que precisam de análise de trade-off antes de assumir o compromisso
- Decisões de nativo versus cross-platform que precisam ser tomadas por custo total e time-to-market, não por preferência técnica
- Aplicativos com forte dependência de WebView buscando rota de migração sem reescrita completa
Sintomas
Se você reconhece três ou mais destes, a oferta provavelmente se aplica.
- O que levava uma sprint agora leva três, e ninguém consegue apontar onde o tempo foi
- Times pisam uns nos outros, e mudança em um módulo quebra outro sem relação aparente
- Existe medo de mexer em certas partes do código, e uma lista informal de quem é o único que entende cada uma
- Toda release é um evento de risco, com janela longa e plano de contingência manual
- A discussão sobre nativo, Flutter ou React Native já dura meses sem decisão
- Decisões arquiteturais antigas não têm registro, e refazer a discussão virou rotina
O que você recebe
- Mapa do estado atual da plataforma e pontos de dor estruturais
- Dois a três cenários de arquitetura-alvo, com custo, risco e prazo de cada um
- Arquitetura-alvo recomendada, com trade-offs registrados em ADR
- Rota de migração incremental, interrompível a cada passo
- Estratégia de release seguro
- Sugestão de estrutura de times e governança
- Advisory mensal de acompanhamento
Fases
Leitura da plataforma
Código, dependências, pipeline, pontos de acoplamento e histórico de incidentes
Opções e trade-offs
Construção de dois a três cenários de arquitetura-alvo, com custo, risco e prazo de cada um
Decisão e registro
Escolha do alvo com quem tem autoridade, e trade-offs registrados em ADR
Rota de migração
Sequência incremental de passos, cada um com valor próprio e ponto de parada seguro
O que não está incluído
- Executar a migração, porque quem implementa é o time do cliente
- Escrever código de produção, abrir PR ou operar release
- Prova de conceito ou protótipo funcional (oferta O4)
- Design de UI, design system ou pesquisa com usuário
- Estimativa detalhada hora a hora, que é a fase 1 da oferta O4
- Instalar processo de specs e agentes (oferta O2)
- Auditoria de segurança (oferta O6)
Como meço sucesso
Combinado antes de começar, não descoberto no fim.
- Existe uma arquitetura-alvo escolhida, e a razão da escolha está registrada em ADR, não na memória de quem estava na reunião
- A rota de migração pode ser interrompida a qualquer passo sem deixar a plataforma pior do que estava
- Cada opção descartada tem o motivo documentado, o que evita refazer a discussão em seis meses
- A liderança consegue defender a decisão fora da área técnica, com custo e prazo
Perguntas frequentes
Você executa a migração?
Não. O squad é sempre do cliente. A oferta entrega o alvo, o racional e a rota, e o advisory mensal acompanha a execução sem entrar nela.
Já sabemos que queremos Flutter. Ainda faz sentido?
Faz, e costuma ser o caso mais útil: a pergunta deixa de ser qual stack e passa a ser como chegar lá sem parar o produto. Se o cenário confirmar a escolha, ela sai registrada com o custo real.
Dá para fazer sem parar o roadmap?
É o único jeito que proponho. A rota incremental existe justamente porque reescrita completa com produto parado é o modo mais caro de modernizar.
E se o problema for de processo, não de arquitetura?
Isso sai na leitura da plataforma, e eu digo na devolutiva. Nesse caso o caminho é a oferta O2, e o levantamento já feito não se perde.
Próximo passo
Uma conversa de 30 minutos para delimitar o escopo. Ao fim dela dá para dizer se esta oferta se aplica e, se não se aplicar, qual das outras se aplica. Isso também é resultado.