> ## 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

# La tua stack list non rilascerà il tuo prodotto

Un centinaio di sviluppatori ha salvato nei preferiti la mia stack list — ciò che la lista tralascia è il plumbing che ha permesso a un tool desktop per Windows di essere rilasciato in 48 ore.

_Pubblicato 2026-10-12._
_Aggiornato il 2026-10-27._

> **Una stack list più lunga aiuta a rilasciare prima?**
> Dipende da ciò che la lista tralascia. Una stack list nomina strumenti; non installa i loro confini — webhook verificati, scoping dei tenant, firma delle release — ed è su quelle giunture che i progetti si fermano. Una lista copiata riproduce gli strumenti senza l'integrazione. Le liste funzionano come un menù di cose da ricercare, ma la strada verso un prodotto rilasciabile è plumbing testato, comunque lo si ottenga. La domanda onesta è quanto valgono le tue sere.

## La trappola dei preferiti

Qualche giorno fa ho risposto a un thread su X con lo stack che uso davvero — il mio «stack da dev indie 2026», una dozzina di strumenti in un'unica risposta. [La risposta](https://x.com/noah_z_zhang/status/2114919719538978934) ha raccolto oltre un centinaio di preferiti e ha portato più di un centinaio di clic a questo sito.

Le analytics sono state meno lusinghiere: la maggior parte dei visitatori ha scansionato una pagina ed è andata via. Una stack list si legge come un piano già finito; una lista copiata non rilascia nulla. Ogni strumento va comunque installato, collegato ai suoi vicini e testato — sono le giunture tra loro a consumare le settimane.

Questo è il post che quei preferiti cercavano: non quali strumenti uso, ma quale plumbing era già portante — e cosa mi ha permesso di rilasciare in quarantotto ore.


## Dove i progetti muoiono davvero

La maggior parte dei progetti indie non muore sulla funzionalità principale. Muore nella prima settimana, su infrastruttura che non ha nulla a che fare con l'idea. La motivazione ha un'emivita di circa quarantotto ore — ogni ora lontano dal prodotto brucia la risorsa più scarsa di chi sviluppa da solo.

La settimana prende una forma sorprendentemente costante:

- Primo giorno: struttura del monorepo, ESLint, path di `tsconfig`, migrazioni del database.
- Terzo giorno: ancora nella documentazione del provider di pagamento, a sistemare l'idempotenza dei webhook.
- Quinto giorno: un companion desktop o mobile — una nuova pipeline di build, una nuova superficie di auth, aggiornamenti automatici da zero.


## Un build in 48 ore, dall'inizio alla fine

La settimana scorsa ho rilasciato [SpinShare](https://spinshare.dev), un'utility desktop nativa per Windows: trascina un file in Explorer, tocca Maiusc e un menu radiale si apre sotto il cursore; rilascia per eseguire una conversione o un'operazione in locale. Nessun popup, nessun upload; il file non lascia mai la macchina.

È la timeline la parte che vale la pena esaminare: nuovo repository, logica core in Rust, un flusso di licenza offline sulle mie rotaie di fatturazione esistenti e una submission al Microsoft Store — quarantotto ore di sviluppo core, in pair coding con un agente e quasi senza ritoccare i prompt. L'agente non ha deragliato per una ragione prosaica: i confini di architettura dove allucina erano già sigillati dentro supastack, il mio kit.

Quello che segue è il rendiconto: il plumbing che non ha dovuto essere costruito in quei due giorni.


## Setup e guardrail

`pnpm setup` comprime il bootstrap in un solo comando: controlli preliminari, allineamento delle variabili d'ambiente, installazione delle dipendenze, migrazioni del database. Non c'è una prima sera passata ad assemblare un ambiente funzionante — il repository supera la propria checklist oppure nomina ciò che manca.

Le doc specchiate in `.ai/`, `AGENTS.md` e `.agents/skills/` sono un contratto scritto per l'agente più che per l'umano — il confine di responsabilità di ogni package, le sue regole di test, le sue linee rosse (l'app desktop è una shell a webview singola che non duplica mai la UI di prodotto). La [guida alla struttura del progetto](https://supastack.dev/it/docs/web/project-structure.md) mostra il layout che l'agente legge; il [post sul workflow con agente](https://supastack.dev/it/blog/building-saas-with-a-coding-agent.md) copre il ritmo di lavoro.

I confini messi per iscritto sono confini che un agente non può attraversare per distrazione.


## Fatturazione e release già pronte

Otto adapter di fatturazione stanno dietro un unico contratto — Stripe, Creem, Polar, Dodo, Lemon Squeezy, Paddle, Whop e PayPal — e un ledger `webhook_event` rende ogni saldo verificato in firma e idempotente prima che diventi una licenza o un'email. Il mio lavoro è iniziato a valle: piani Early-Bird che cambiano in base al numero di ordini e chiavi di licenza offline firmate Ed25519 — un tool desktop deve attivarsi senza una chiamata di rete. La [guida al modulo di fatturazione](https://supastack.dev/it/docs/modules/billing.md) documenta il flusso che ho esteso.

Il lato release era altrettanto privo di interesse, ed è proprio questo il punto. La pipeline Tauri 2 — `desktop-release.yml` — costruisce bundle firmati e genera `latest.json` via minisign per i canali stable e beta su Windows (NSIS e msi), macOS (dmg) e Linux (AppImage). L'unico packaging fatto da me è stato un build MSIX per il Microsoft Store; il [quickstart desktop](https://supastack.dev/it/docs/desktop/ship-in-5-minutes.md) copre il resto.


## Il dieci per cento che gli utenti sentono davvero

Ecco l'aritmetica che una stack list nasconde. Circa il novanta per cento di ciò che serve a un prodotto è plumbing che l'utente non vede mai. Il plumbing invisibile è il lavoro che una fondazione dovrebbe portare — è la parte che può essere portata. Il resto è il prodotto.

Poiché il mio era già portante, quasi tutte le mie quarantotto ore sono andate al dieci per cento che gli utenti possono sentire — lavoro che non entra mai in un commento sullo stack e che non succede mai quando la settimana se ne va tra webhook e firme:

- Hook di trascinamento OLE di Windows in Rust, così il menu si arma solo mentre un vero drag di file è tenuto premuto con Maiusc — mai durante la digitazione.
- Un flusso multi-finestra nella tray di sistema, così il tool resta a una pressione di distanza senza una finestra nella barra delle applicazioni.
- L'animazione del menu radiale, rifinita finché il menu non si legge come istantaneo invece che animato.
- Più di trenta convertitori di formati locali, ciascuno con i propri test unitari.


## La parte pratica: prezzi e trasparenza

L'obiezione giusta: «Ho Cursor — perché pagare per una stack list?» Regge finché il tuo tempo non ha un prezzo. Due sere di idempotenza dei webhook ti costano una funzionalità che non hai rilasciato.

Sulla trasparenza: la [documentazione](https://supastack.dev/it/docs/web/ship-in-5-minutes.md) è pubblica per intero — struttura delle directory, doppio motore web, sincronizzazione multipiattaforma, tutti gli otto adapter di fatturazione, routing AI. Preferisco che uno scettico la legga tutta e se ne vada piuttosto che comprare su un titolo; [starter kit o da zero](https://supastack.dev/it/blog/starter-kit-or-from-scratch.md) è la versione onesta della decisione.

Due note pratiche: i prezzi mostrati includono già 100 $ di risparmio per il lancio, e il checkout supporta Alipay. E un cashback del 50% per i builder — rilascia un prodotto reale entro sessanta giorni, condividi pubblicamente la storia del build (5.000 visualizzazioni organiche o 50 like organici su X, Reddit, YouTube o simili) e mandami il link via email: metà ti torna indietro e la licenza resta tua. Le regole sono nei [termini del launch-cashback](https://supastack.dev/terms#launch-cashback).


## Domande frequenti sulle stack list

Le stesse obiezioni riaffiorano ogni volta che il kit viene nominato. Meritano risposte dirette.

- Un agente non può fare lo scaffold di tutto questo per me? — Può produrre qualcosa di plausibile; non può verificare le giunture in una sola passata. Un webhook idempotente si testa, non si genera — lo scaffold ti rimette in mano la stessa lista.
- Un boilerplate non rende i prodotti generici? — Il plumbing è condiviso; il prodotto no. Gli hook di trascinamento, il comportamento nella tray e i convertitori di SpinShare non esistono da nessuna parte nel kit — il dieci per cento che i clienti vedono resta tuo.
- E se mi serve solo una web app? — Il kit è l'acquisto in ogni caso; mobile e desktop sono superfici da adottare o ignorare, non requisiti. SpinShare esiste perché la superficie desktop era già costruita.
- Un'utility desktop è davvero la storia dell'acquirente? — È l'esempio onesto più breve che ho: due giorni da un repository vuoto a una submission in uno store. Lo stesso plumbing serve un SaaS — la [checklist di lancio](https://supastack.dev/it/blog/saas-launch-checklist.md) è la versione lunga.
- Perché non pubblicare semplicemente la stack list? — Fatto: la [guida allo stack tecnico](https://supastack.dev/it/docs/web/tech-stack.md) nomina ogni scelta e la sua ragione. Una lista è un menù, non un piano — qui la tesi è comprare il piano già costruito.