Escolhe à volta dos requisitos do produto
Anota o que o produto precisa antes de comparar nomes de frameworks. Um dashboard web, uma ferramenta mobile offline e um fluxo de pesquisa longo têm requisitos diferentes. Decide que clientes serves, que dados pertencem a cada cliente e que operações devem continuar depois de um separador fechar.
Pondera a experiência da tua equipa ao lado das listas de funcionalidades. Um stack familiar com limites claros pode ser mais fácil de manter do que uma combinação mais recente que exige aprender auth, deployment e convenções de persistência ao mesmo tempo. Conta o trabalho contínuo de atualizações e depuração, não só a primeira instalação.
- Que superfícies de cliente precisas no primeiro dia — só web, ou mobile e desktop também.
- Que dados pertencem a cada cliente, e se as equipas partilham workspaces.
- Que operações têm de sobreviver a um separador fechado: jobs em fila, trabalho agendado, tarefas de longa duração.
- Pelo que vais cobrar — subscrições, lugares, utilização — e quem paga por isso.
- Quanta superfície operacional a tua equipa consegue realisticamente correr: bases de dados, filas, fornecedores.
Avalia as camadas por baixo da framework
Os nomes de frameworks descrevem a superfície. As camadas por baixo decidem se o produto se mantém coeso. Percorre-as uma a uma e faz a cada a mesma pergunta: quem é dono desta decisão, e onde é aplicada?
Trata qualquer camada que um stack deixe em branco como trabalho que estás a contratar. «Traz a tua própria auth» é um desenho legítimo — significa apenas que serás dono da semântica de sessões, das integrações de fornecedores e de cada caso de falha que daí vem. Camadas em branco são uma escolha; camadas invisíveis são um risco. A documentação de módulos do kit é uma referência útil para o aspeto real de uma camada com dono.
| Camada | A pergunta a responder |
|---|---|
| Identidade | Quem emite e verifica sessões, em cada superfície? |
| Dados | Como é cada registo delimitado ao cliente que o detém? |
| Faturação | Onde é que um evento de pagamento se torna acesso, e quem o revoga? |
| Trabalho em segundo plano | O que acontece quando um job falha, tenta de novo ou corre duas vezes? |
| AI e fornecedores | Quem detém as chaves, a escolha de modelo e o limite de gasto? |
| Operações | Como correm realmente segredos, logs, backups e upgrades? |
Inspeciona as junções entre ferramentas
Um stack é um conjunto de decisões de integração. Identifica quem possui as sessões, como os registos são delimitados, onde um evento de pagamento se torna uma permissão e como a UI obtém o resultado do trabalho em segundo plano. Essas ligações determinam se o caminho feliz permanece correto quando os pedidos falham ou chegam duplicados.
O supastack usa Next.js para a superfície web, Expo para mobile e pacotes TypeScript partilhados por baixo. O Better Auth possui a identidade, Postgres e Drizzle persistem registos e o Trigger.dev possui a semântica de workflow explícita. São escolhas do repo, não uma afirmação de que cada produto deva usar as mesmas ferramentas — o guia de stack tecnológica regista cada escolha e a sua razão, e as perguntas transferem-se mesmo que escolhas ferramentas diferentes.
Quaisquer que sejam as ferramentas, o teste é o mesmo: escolhe um registo e segue-o da interface, através da fronteira de servidor, até à persistência e de volta. Se algum salto for uma convenção em vez de uma regra aplicada, um futuro contribuidor acabará por o partir.
Conta o custo de o manter a correr
Uma decisão de stack é também uma decisão de operações. O Postgres precisa de backups e disciplina de migrações. Um runner de jobs precisa de um dashboard que alguém realmente abra. Cada chave de fornecedor precisa de rotação e de um lar fora dos bundles de cliente. Adiciona estas linhas à comparação antes de a checklist de funcionalidades te convencer.
Verifica o caminho de atualização enquanto ainda tens opções. Um monorepo com dependências fixadas e um processo de atualização documentado — o kit mantém um guia de atualização exatamente para isto — envelhece melhor do que um stack montado a partir de tutoriais que assumem cada um uma versão diferente do mundo.
- Atualizações de dependências e de segurança: com que frequência chegam, e quem as aplica.
- Credenciais de fornecedor: onde vivem, e quem as pode rodar.
- Dados: um agendamento de backups, um exercício de restauro e uma política de retenção.
- Observabilidade: o que falha ruidosamente, e o que falha em silêncio até um cliente o reportar.
Constrói uma pequena fatia vertical
Antes de te comprometeres com um stack, executa uma fatia que liga um utilizador, escreve um registo próprio, inicia trabalho e obtém um resultado. Depois tenta deliberadamente o workspace errado, uma sessão expirada e um job falhado. Avalia quanta cola personalizada estas condições comuns exigem.
Mantém um registo de decisão curto: o que o stack suporta, o que escolhes adiar e o que desencadearia uma revisão. Compras nativas, aceitação real de fornecedores e operações de deployment devem ser itens explícitos em vez de suposições escondidas atrás de um build local bem-sucedido. O stack certo deixa à equipa atenção suficiente para trabalhar no produto.
Se a fatia correr bem dentro do repositório de um starter, a pergunta seguinte é se o deves adotar — starter kit ou do zero percorre essa decisão.
- Inicia sessão e restaura-a depois de um recarregamento.
- Escreve um registo delimitado a um workspace e lê-o de volta.
- Inicia uma tarefa em segundo plano e obtém o resultado mais tarde.
- Repete as mesmas chamadas a partir do workspace errado e de uma sessão expirada.
Perguntas frequentes sobre a escolha de um stack
As decisões de stack atraem muitos conselhos confiantes. Estas são as perguntas que vale a pena responder para o teu próprio produto.
- Devo escolher o stack que já conheço? — Normalmente sim, quando consegue expressar os requisitos do produto. Um stack familiar com limites claros vence um da moda que passarás meses a aprender — a menos que o produto exija genuinamente algo que lhe falta, como mobile nativo.
- A framework de front-end é o que mais importa? — Menos do que as camadas à sua volta. A framework molda a UI; a identidade, a delimitação, a faturação e o trabalho em segundo plano decidem se o produto se mantém correto.
- Quanto tempo deve durar uma avaliação de stack? — Dias, não semanas: escreve os requisitos, inspeciona as junções e executa uma fatia vertical. Se falhas comuns precisarem de cola à medida, continua a procurar.
- Quando se justifica trocar de stack mais tarde? — Quando um requisito central muda — uma plataforma obrigatória, um limiar de escala — não quando uma versão mais recente parece mais bonita. O custo da troca vive na auth e nos dados, não nos componentes.