Uma base sobre a qual construir.

O trabalho que cada produto repete

Um produto novo começa com um problema particular. As suas primeiras semanas parecem muitas vezes bem menos particulares: sessões, registos de workspace, estado de subscrição, trabalho em segundo plano e entrega de email. Estas peças têm de cooperar antes de o produto conseguir fazer algo útil — cada uma é um problema resolvido no abstrato e um risco de integração no concreto.

O supastack dá um lar a esse trabalho repetido. Uma app web Next.js e uma app mobile Expo partilham pacotes TypeScript para a infraestrutura subjacente. O objetivo é tornar esses limites suficientemente compreensíveis para um produto os configurar sem herdar o modelo de domínio de outro.

Nenhuma das peças é difícil isoladamente. O custo vive na sua coordenação — um pagamento que tem de se tornar uma permissão, uma sessão que tem de se tornar um âmbito de workspace, uma tarefa que tem de sobreviver a um portátil fechado. Os produtos raramente falham por uma funcionalidade em falta. Falham numa junção.

Porquê construí-lo uma vez, bem

O argumento para infraestrutura partilhada não é que o trabalho esteja abaixo de ti — é que o trabalho repetido merece ser feito uma vez, com cuidado. Um limite de workspace bem implementado num módulo partilhado protege cada produto construído sobre ele. O mesmo limite improvisado por produto torna-se um conjunto de quase-acertos que diferem de formas interessantes e perigosas.

Também concentra a manutenção. As APIs de fornecedores mudam, as bibliotecas de auth evoluem, a semântica de faturação desvia-se. Quando essas mudanças aterram num só lugar — a documentação de módulos do kit acompanha-as — uma correção propaga-se em vez de ser reaprendida por projeto. E quando pesas a troca para um único produto, starter kit ou do zero aplica o mesmo raciocínio à decisão comprar-versus-construir.

A infraestrutura partilhada também concentra a revisão. Um limite que vive num só lugar pode ser testado a fundo uma vez — casos negativos, eventos repetidos, tentativas entre tenants — em vez de esperar que cinco reimplementações tenham acertado cada uma. É parte do porquê de o kit investir na sua suite de testes: manter confiança em código partilhado é mais barato do que a reconquistar por projeto.

Dá a cada módulo uma responsabilidade

A identidade estabelece quem faz um pedido. Os workspaces determinam a que registos essa pessoa pode aceder. A faturação regista o estado de pagamento, enquanto as permissões respondem se uma capacidade está disponível. Manter estas preocupações separadas impede que um redirecionamento de pagamento bem-sucedido se torne uma decisão de autorização.

A mesma disciplina aplica-se ao trabalho em segundo plano. O contrato JobRunner partilhado promete enqueue, status e cancel. O Trigger.dev possui o comportamento de workflow. Uma interface pequena tem valor quando os seus limites são visíveis; esconder retries ou agendamento atrás de um método genérico tornaria o sistema mais difícil de raciocinar.

O Better Auth responde à identidade. O Postgres e o Drizzle guardam os registos. A Stripe ou a Lemon Squeezy reportam o estado de pagamento. A nenhum deles se pede esperteza sobre o trabalho de outro módulo — as junções ficam estreitas o suficiente para raciocinar sobre elas — e uma base só é tão fiável quanto as suas junções.

Deixa espaço para o produto

Um fluxo de leads, um editor de documentos e um assistente de pesquisa podem usar os mesmos módulos de identidade e faturação. Os seus registos, linguagem e fluxos permanecem diferentes. A lógica própria do produto pertence ao codebase consumidor, com a configuração que a liga à base.

Essa separação é também uma decisão prática de manutenção. Uma correção de isolamento de workspace deve ser reutilizável. Uma mudança em como um produto avalia um lead não deve tornar-se um novo requisito para todos os outros produtos.

Essa é a diferença entre uma base e um tema. Um tema dá-te um visual para manter ou substituir. Uma base dá-te decisões estruturais — quem detém a identidade, como os registos são delimitados, onde um pagamento se torna acesso — sobre as quais um produto constrói em vez de contornar. O guia de estrutura do projeto mostra onde uma acaba e o outro começa.

Começa por um fluxo completo

Começa com o fluxo de referência local: inicia sessão, inspeciona o acesso, submete uma tarefa e lê o seu resultado. Adaptadores fake e locais permitem que testes deterministas exercitem o caminho sem pedidos pagos a fornecedores — o quickstart de cinco minutos corre-o de ponta a ponta. Configura depois as integrações de produção de que o teu produto realmente precisa.

A aceitação local e a aceitação de produção respondem a perguntas diferentes. Um teste local que passa estabelece o comportamento da aplicação em condições controladas. Persistência real de auth, entrega de fornecedores, deployment e comportamento em dispositivo ainda precisam da sua própria verificação. Mantém essa distinção visível à medida que o produto cresce.

Uma base ganha o seu nome devagar: no segundo produto que sai mais depressa do que o primeiro, e no dia de manutenção que corrige um módulo em vez de cinco codebases. Essa é a aposta por trás do supastack — e é a fasquia exigida a cada módulo.

Perguntas por trás da abordagem

Algumas perguntas estão por baixo desta abordagem, e merecem uma resposta franca.

• O supastack é um template ou uma framework? — Uma base de módulos com contratos entre eles. O código de produto vive fora do Starter Core e liga-se através de configuração, por isso a plataforma pode ser atualizada sem bifurcar as tuas funcionalidades.
• A infraestrutura partilhada não torna os produtos genéricos? — Só a canalização é partilhada. Registos, fluxos e linguagem ficam no codebase do produto — as partes que os clientes realmente veem continuam tuas.
• Onde começa o código próprio do produto? — Nos registos e fluxos que só ele tem. A base autentica o utilizador e delimita os dados; não sabe o que é um prospect.
• Porquê um monorepo? — Para que as apps web, mobile e desktop mudem junto com os pacotes por baixo delas: um sistema de tipos, uma porta de testes, sem desvio entre repositórios.
• E se eu só precisar da app web? — A base é a compra; mobile e desktop são superfícies para adotar ou ignorar. Nada te obriga a entregar uma app de que não precisas.