> ## Documentation Index
> Fetch the complete documentation index at: https://supastack.dev/llms.txt
> Use this file to discover all available pages before exploring further.
> For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt

# A tua lista de stack não vai lançar o teu produto

Uma centena de programadores guardou nos favoritos a minha lista de stack — o que a lista deixa de fora é a canalização que permitiu lançar uma ferramenta de desktop para Windows em 48 horas.

_Publicado 2026-10-12._
_Atualizado em 2026-10-27._

> **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](https://x.com/noah_z_zhang/status/2114919719538978934) 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](https://spinshare.dev), 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](https://supastack.dev/pt/docs/web/project-structure.md) mostra o layout que ele lê; o [post sobre o fluxo com agentes](https://supastack.dev/pt/blog/building-saas-with-a-coding-agent.md) 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](https://supastack.dev/pt/docs/modules/billing.md) 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](https://supastack.dev/pt/docs/desktop/ship-in-5-minutes.md) 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](https://supastack.dev/pt/docs/web/ship-in-5-minutes.md) é 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](https://supastack.dev/pt/blog/starter-kit-or-from-scratch.md) é 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](https://supastack.dev/terms#launch-cashback).


## 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](https://supastack.dev/pt/blog/saas-launch-checklist.md) é a versão mais longa.
- Por que não publicar simplesmente a lista de stack? — Feito: o [guia de stack tecnológica](https://supastack.dev/pt/docs/web/tech-stack.md) 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.