Uma lista de stack mais comprida ajuda-te a lançar mais depressa?
Depende do que a lista deixa de fora. Uma lista de stack nomeia ferramentas; não instala as fronteiras entre elas — webhooks verificados, delimitação de tenants, assinatura de releases — e é nessas junções que os projetos encalham. Uma lista copiada reproduz as ferramentas sem nada da integração. As listas servem como menu de coisas a pesquisar, mas o caminho para um produto lançável é canalização testada, venha ela de onde vier. A pergunta honesta é quanto valem os teus serões.
A armadilha dos favoritos
Há uns dias respondi a uma thread no X com o stack que realmente uso — o meu «stack indie dev 2026», uma dúzia de ferramentas numa só resposta. A resposta colecionou mais de cem favoritos e trouxe mais de cem cliques para este site.
As analíticas foram menos lisonjeiras: a maioria dos visitantes percorreu uma página e saiu. Uma lista de stack lê-se como um plano terminado; uma lista copiada não lança nada. Cada ferramenta continua a ter de ser instalada, ligada às vizinhas e testada — as junções entre elas são para onde vão as semanas.
Este é o post que os favoritos procuravam: não que ferramentas uso, mas que canalização já era estrutural — e o que isso me deixou lançar em quarenta e oito horas.
Onde os projetos morrem de facto
A maioria dos projetos indie não morre na sua funcionalidade central. Morre na primeira semana, em infraestrutura que nada tem a ver com a ideia. A motivação tem uma meia-vida de cerca de quarenta e oito horas — cada hora longe do produto queima o recurso mais escasso que um build a solo tem.
A forma da semana é notavelmente consistente:
- Dia um: layout de monorepo, ESLint, paths de
tsconfig, migrações de base de dados. - Dia três: ainda na documentação do fornecedor de pagamentos, a acertar a idempotência dos webhooks.
- Dia cinco: um companheiro desktop ou mobile — um pipeline de build novo, uma superfície de auth nova, atualizações automáticas a partir do zero.
Um build de 48 horas, de ponta a ponta
Na semana passada lancei o SpinShare, uma utilidade de desktop nativa do Windows: arrasta um ficheiro no Explorador, toca em Shift e um menu radial abre sob o cursor; solta para executar uma conversão ou operação local. Sem popups, nada é enviado — o ficheiro nunca sai da máquina.
A cronologia é a parte que vale a pena examinar: repositório novo, lógica central em Rust, um fluxo de licenças offline sobre os meus trilhos de faturação existentes e uma submissão à Microsoft Store — quarenta e oito horas de desenvolvimento central, a programar em par com um agente e quase sem afinar prompts. O agente não descarrilou por uma razão pouco glamorosa: as fronteiras de arquitetura onde ele alucina já estavam seladas dentro do supastack, o meu próprio kit.
O que se segue é a contabilidade: a canalização que não teve de ser construída naqueles dois dias.
Configuração e guarda-corpos
O pnpm setup colapsa o arranque num só comando: verificações preliminares, alinhamento de variáveis de ambiente, instalação de dependências, migrações de base de dados. Não há uma primeira noite a montar um ambiente de trabalho — o repositório ou passa a sua própria checklist ou aponta o que falta.
Os documentos espelho do .ai/, o AGENTS.md e .agents/skills/ são um contrato escrito para o agente e não para o humano — a fronteira de responsabilidade de cada pacote, as suas regras de teste, as suas linhas vermelhas (a aplicação desktop é um shell de uma só webview que nunca bifurca a UI do produto). O guia de estrutura do projeto mostra o layout que ele lê; o post sobre o fluxo com agentes cobre o ritmo de trabalho.
Fronteiras que ficam escritas são fronteiras que um agente não consegue atravessar por descuido.
Faturação e releases já prontas
Oito adaptadores de faturação vivem atrás de um só contrato — Stripe, Creem, Polar, Dodo, Lemon Squeezy, Paddle, Whop e PayPal — e um registo webhook_event faz com que cada liquidação chegue com assinatura verificada e idempotente antes de se tornar uma licença ou um e-mail. O meu trabalho começou a jusante: escalões Early-Bird que mudam consoante o número de encomendas e chaves de licença offline assinadas com Ed25519 — uma ferramenta de desktop tem de ativar sem chamada de rede. O guia do módulo de faturação documenta o fluxo que estendi.
O lado dos releases foi igualmente desinteressante, que é exatamente a ideia. O pipeline de Tauri 2 — desktop-release.yml — constrói bundles assinados e gera o latest.json via minisign para os canais estável e beta em Windows (NSIS e msi), macOS (dmg) e Linux (AppImage). O único trabalho de empacotamento que fiz foi um build MSIX para a Microsoft Store; o quickstart de desktop cobre o resto.
Os dez por cento que os utilizadores realmente sentem
Esta é a aritmética que uma lista de stack esconde. Cerca de noventa por cento do que um produto precisa é canalização que o utilizador nunca vê. A canalização invisível é o trabalho que uma fundação deve carregar — é a parte que pode ser carregada. O resto é o produto.
Como a minha já era estrutural, quase todas as minhas quarenta e oito horas foram para os dez por cento que os utilizadores sentem — trabalho que nunca cabe num comentário de stack e que nunca acontece enquanto a semana se vai em webhooks e assinaturas:
- Hooks de arrasto OLE do Windows em Rust, para que o menu só se ative enquanto um arrasto real de ficheiro é mantido com Shift — nunca enquanto se escreve.
- Um fluxo de bandeja com várias janelas, para que a ferramenta fique a uma tecla de distância sem uma janela na barra de tarefas.
- A animação do menu radial, afinada até o menu parecer instantâneo em vez de animado.
- Mais de trinta conversores de formato locais, cada um com os seus próprios testes unitários.
A parte prática: preço e transparência
A objeção justa: «Tenho o Cursor — porque haveria de pagar por uma lista de stack?» Aguanta até o teu próprio tempo ter um preço. Duas noites de idempotência de webhooks custam-te uma funcionalidade que não lançaste.
Sobre a transparência: a documentação é pública na íntegra — estrutura de diretórios, dois motores web, sincronização multiplataforma, os oito adaptadores de faturação, encaminhamento de IA. Prefiro que um cético a leia de ponta a ponta e vá embora a que compre por um título; starter kit ou do zero é a versão honesta da decisão.
Duas notas práticas: os preços apresentados já incluem 100 USD de poupança de lançamento e o checkout aceita Alipay. E um cashback de 50% para builders — lança um produto real em sessenta dias, partilha a história do build publicamente (5.000 visualizações orgânicas ou 50 curtidas orgânicas no X, Reddit, YouTube ou similar) e envia-me o link por e-mail: metade volta e a licença fica tua. As regras estão nos termos do cashback de lançamento.
Perguntas frequentes sobre listas de stack
As mesmas objeções surgem sempre que o kit surge. Merecem respostas diretas.
- Um agente não consegue montar tudo isto por mim? — Consegue produzir algo plausível; não consegue verificar as junções numa só passagem. Um webhook idempotente testa-se, não se gera — o scaffolding entrega-te a mesma lista outra vez.
- Um boilerplate não torna os produtos genéricos? — A canalização é partilhada; o produto não. Os hooks de arrasto, o comportamento de bandeja e os conversores do SpinShare não existem em lado nenhum do kit — os dez por cento que os clientes veem ficam teus.
- E se só precisar de uma app web? — O kit é a compra de qualquer forma; mobile e desktop são superfícies para adotar ou ignorar, não requisitos. O SpinShare existe porque a superfície de desktop já estava construída.
- Uma utilidade de desktop é mesmo a história do comprador? — É o exemplo honesto mais curto que tenho: dois dias de um repositório vazio a uma submissão à loja. A mesma canalização serve um SaaS — a checklist de lançamento é a versão mais longa.
- Por que não publicar simplesmente a lista de stack? — Feito: o guia de stack tecnológica nomeia cada escolha e a sua razão. Uma lista é uma ementa, não um plano — o argumento aqui é comprar o plano já construído.