Qual é o momento do produto?MVP validando mercadoA prioridade é entregar rápido, aprender e mudar sem cerimônia.Melhor para: Times pequenos, backlog instável e poucas regras de domínio.Evite se: Já existem muitos domínios ou integrações críticas.Produto ganhando escalaNovas jornadas surgem, o time cresce e o código precisa de limites.Melhor para: Produtos que saíram do MVP e precisam organizar crescimento.Evite se: Cada time já precisa publicar sua parte de forma independente.Produto crítico e longevoO frontend contém regras importantes e terá muitos anos de evolução.Melhor para: Sistemas com risco, auditoria, regras complexas ou alto custo de erro.Evite se: A interface apenas consome CRUD simples.
Como o trabalho é dividido entre times?Um time dono do appPoucas pessoas mantêm o frontend e combinam releases juntas.Melhor para: Simplicidade, decisões rápidas e baixo custo operacional.Evite se: Existem vários produtos ou domínios compartilhando código.Vários apps relacionadosPortal, admin, docs, design system e libs evoluem juntos.Melhor para: Organizações que precisam reaproveitar UI, tipos e ferramentas.Evite se: Os times precisam deployar partes totalmente isoladas.Times autônomos por domínioCada time quer publicar, operar e versionar sua parte.Melhor para: Organizações grandes com ownership bem definido.Evite se: Ainda não há maturidade de contratos, observabilidade e CI/CD.
Onde ficam as regras de negócio?Quase tudo no backendO frontend exibe dados, valida campos simples e envia ações.Melhor para: CRUDs, painéis internos e interfaces com pouca regra local.Evite se: Há estados ricos, políticas ou cálculos importantes no browser.Regras divididasParte está no backend, mas a UI orquestra fluxos e decisões.Melhor para: Jornadas com estado, permissões de tela e ações de produto.Evite se: As regras precisam ser modeladas com linguagem de domínio forte.Frontend tem domínio ricoA interface representa políticas, casos de uso e linguagem do negócio.Melhor para: Produtos financeiros, healthtech, logística, cobrança e compliance.Evite se: O time ainda não domina o problema de negócio.
Como os dados chegam à tela?Uma API principalContratos simples, pouca agregação e baixa transformação.Melhor para: Apps com backend dedicado e payloads próximos da UI.Evite se: A tela precisa compor muitas fontes de dados.Várias fontes agregadasA mesma tela precisa dados de serviços diferentes.Melhor para: Dashboards, home pages e jornadas que combinam domínios.Evite se: Você não pode manter uma camada backend dedicada ao frontend.Eventos, realtime ou colaboraçãoA UI reage a ações, notificações, sockets ou eventos assíncronos.Melhor para: Produtos colaborativos, notificações, analytics e atualização em tempo real.Evite se: O fluxo é linear e fácil de seguir com chamadas diretas.
Como você precisa entregar mudanças?Deploy único e previsívelTodos combinam release e preferem uma operação simples.Melhor para: Times centralizados e produtos sem necessidade de independência operacional.Evite se: Domínios precisam evoluir em calendários diferentes.Mudanças coordenadas entre appsRefatorações devem atravessar apps e libs com segurança.Melhor para: Monorepos, design systems e pacotes compartilhados.Evite se: Cada app pertence a uma organização ou pipeline independente.Deploy independente por domínioCada time precisa publicar sua parte sem esperar o shell inteiro.Melhor para: Ambientes com governança forte de contratos e observabilidade.Evite se: O custo de runtime e integração ainda não cabe no time.
Qual tipo de experiência o usuário consome?Aplicação operacionalUsuários trabalham em fluxos repetidos, tabelas e formulários.Melhor para: SaaS, CRM, backoffice e painéis administrativos.Evite se: SEO e conteúdo estático são prioridade maior que interatividade.Conteúdo com poucas ilhas interativasA maioria da página é estática, mas alguns blocos precisam JS.Melhor para: E-commerce editorial, sites de conteúdo e páginas SEO-driven.Evite se: O produto é uma aplicação interativa de ponta a ponta.Experiência compostaA tela mistura módulos de domínios diferentes no mesmo shell.Melhor para: Portais, marketplaces e plataformas com áreas independentes.Evite se: Não há contratos maduros entre times.
Como é o estado da interface?Estado local simplesFiltros, formulários e seleção de itens resolvem a maior parte.Melhor para: Interfaces CRUD e fluxos curtos.Evite se: Você precisa rastrear intenções e consistência eventual.Estado por jornadaCada feature mantém estado próprio e coordena ações de tela.Melhor para: Checkout, onboarding, configuração e fluxos multi-etapa.Evite se: O estado cruza muitos domínios independentes.Comandos, eventos e consistência eventualA UI precisa refletir ações assíncronas e modelos de leitura.Melhor para: Pedidos, pagamentos, colaboração e integrações assíncronas.Evite se: Tudo acontece de forma síncrona e linear.