Una base su cui costruire.

Il lavoro che ogni prodotto ripete

Un prodotto nuovo inizia con un problema particolare. Le sue prime settimane sembrano spesso molto meno particolari: sessioni, record di workspace, stato dell'abbonamento, lavoro in background e consegna email. Questi pezzi devono cooperare prima che il prodotto possa fare qualcosa di utile — ciascuno è un problema risolto in astratto e un rischio di integrazione nel concreto.

supastack dà una casa a quel lavoro ripetuto. Un'app web Next.js e un'app mobile Expo condividono pacchetti TypeScript per l'infrastruttura sottostante. L'obiettivo è rendere quei confini abbastanza comprensibili da permettere a un prodotto di configurarli senza ereditare il modello di dominio di qualcun altro.

Nessuno dei pezzi è difficile in isolamento. Il costo vive nel loro coordinamento — un pagamento che deve diventare un permesso, una sessione che deve diventare una delimitazione di workspace, un'attività che deve sopravvivere a un laptop chiuso. I prodotti raramente falliscono per una funzionalità mancante. Falliscono su una giunzione.

Perché costruirlo una volta sola, bene

L'argomento a favore dell'infrastruttura condivisa non è che il lavoro sia al di sotto di te — è che il lavoro ripetuto merita di essere fatto una volta, con cura. Un confine di workspace implementato bene in un modulo condiviso protegge ogni prodotto costruito sopra. Lo stesso confine improvvisato prodotto per prodotto diventa un insieme di quasi-successi che differiscono in modi interessanti e pericolosi.

Concentra anche la manutenzione. Le API dei provider cambiano, le librerie di auth evolvono, la semantica della fatturazione deriva. Quando quei cambiamenti arrivano in un solo posto — la documentazione dei moduli del kit li traccia — una correzione si propaga invece di essere re-imparata progetto per progetto. E quando stai pesando lo scambio per un singolo prodotto, starter kit o da zero applica lo stesso ragionamento alla decisione comprare-contro-costruire.

L'infrastruttura condivisa concentra anche la revisione. Un confine che vive in un solo posto può essere testato a fondo una volta — casi negativi, eventi ripetuti, tentativi tra tenant — invece di sperare che cinque reimplementazioni l'abbiano fatto giusto ciascuna. È parte del motivo per cui il kit investe nella sua suite di test: mantenere fiducia nel codice condiviso costa meno che riguadagnarla progetto per progetto.

Dai a ogni modulo una responsabilità

L'identità stabilisce chi fa una richiesta. I workspace determinano a quali record quella persona può accedere. La fatturazione registra lo stato di pagamento, mentre i permessi rispondono se una capacità è disponibile. Tenere separate queste preoccupazioni impedisce che un redirect di pagamento riuscito diventi una decisione di autorizzazione.

La stessa disciplina si applica al lavoro in background. Il contratto JobRunner condiviso promette enqueue, status e cancel. Trigger.dev possiede il comportamento del workflow. Una piccola interfaccia ha valore quando i suoi confini sono visibili; nascondere retry o scheduling dietro un metodo generico renderebbe il sistema più difficile da ragionare.

Better Auth risponde all'identità. Postgres e Drizzle custodiscono i record. Stripe o Lemon Squeezy riportano lo stato dei pagamenti. A nessuno di loro viene chiesto di essere furbo sul lavoro di un altro modulo — le giunzioni restano abbastanza strette da poterle ragionare — e una base è affidabile quanto le sue giunzioni.

Lascia spazio al prodotto

Un flusso di lead, un editor di documenti e un assistente di ricerca possono usare gli stessi moduli di identità e fatturazione. I loro record, il linguaggio e i flussi restano diversi. La logica specifica del prodotto appartiene al codebase consumatore, con la configurazione che la collega alla base.

Quella separazione è anche una decisione pratica di manutenzione. Una correzione all'isolamento dei workspace dovrebbe essere riutilizzabile. Un cambiamento nel modo in cui un prodotto valuta un lead non dovrebbe diventare un nuovo requisito per ogni altro prodotto.

Questa è la differenza tra una base e un tema. Un tema ti dà un aspetto da tenere o sostituire. Una base ti dà decisioni portanti — chi possiede l'identità, come vengono delimitati i record, dove un pagamento diventa accesso — su cui un prodotto costruisce invece di lavorarci attorno. La guida alla struttura del progetto mostra dove finisce l'una e inizia l'altra.

Inizia da un flusso completo

Parti dal flusso di riferimento locale: accedi, ispeziona l'accesso, invia un'attività e leggi il suo risultato. Gli adattatori fake e locali permettono a test deterministici di esercitare il percorso senza richieste a pagamento ai provider — il quickstart di cinque minuti lo esegue da un capo all'altro. Configura poi le integrazioni di produzione di cui il tuo prodotto ha davvero bisogno.

Accettazione locale e accettazione in produzione rispondono a domande diverse. Un test locale superato stabilisce il comportamento dell'applicazione in condizioni controllate. Persistenza reale dell'auth, consegna dei provider, deployment e comportamento su dispositivo richiedono ancora la propria verifica. Mantieni visibile quella distinzione man mano che il prodotto cresce.

Una base si guadagna il suo nome lentamente: nel secondo prodotto che parte più veloce del primo, e nel giorno di manutenzione che sistema un modulo invece di cinque codebase. Questa è la scommessa dietro supastack — ed è l'asticella a cui ogni modulo è tenuto.

Le domande dietro l'approccio

Alcune domande stanno sotto questo approccio, e vale la pena rispondere in modo diretto.

• supastack è un template o un framework? — Una base di moduli con contratti tra loro. Il codice di prodotto vive fuori da Starter Core e si collega tramite configurazione, così la piattaforma può essere aggiornata senza forkare le tue funzionalità.
• L'infrastruttura condivisa non renderà i prodotti generici? — Solo le tubature sono condivise. Record, workflow e linguaggio restano nel codebase del prodotto — le parti che i clienti vedono davvero restano tue.
• Dove inizia il codice proprio del prodotto? — Con i record e i workflow che solo lui possiede. La base autentica l'utente e delimita i dati; non sa cosa sia un lead.
• Perché un monorepo? — Perché le app web, mobile e desktop cambino insieme ai pacchetti sotto di loro: un solo type system, un solo gate di test, nessuna deriva tra repository.
• E se mi serve solo l'app web? — La base è l'acquisto; mobile e desktop sono superfici da adottare o ignorare. Nulla ti obbliga a distribuire un'app che non ti serve.