Sistema minimo vitale per solo founder: sito, prodotto, pagamenti, dati e automazione

Apri launch-checklist.md: la pagina /pricing esiste, ma Stripe Product no; il login funziona, ma lo stato dell’abbonamento non è sincronizzato; GA4 riceve page_view, ma il clic sul pulsante di pagamento non genera un evento; il modulo invia un’email, ma non crea un’attività.

Molti sviluppatori indipendenti considerano “funziona” un criterio di lancio. Le lacune emergono quando un cliente pagante richiede ancora un’attivazione manuale o una quota gratuita viene superata prima che qualcuno controlli i consumi.

Un sistema minimo vitale per solo founder non è vitale perché usa pochi strumenti. Le azioni aziendali devono arrivare al risultato: la persona entra, riceve il prodotto, paga, ottiene l’accesso, genera dati utili, invia feedback e trova assistenza quando qualcosa non funziona.

La prima tabella aiuta a individuare la consegna interrotta. In seguito puoi decidere quali livelli richiedono una versione minima e quali possono aspettare.

Tabella di accettazione: interfacce da chiudere prima del lancio

Il criterio di accettazione non è “tutte le funzioni esistono”, ma la capacità di ogni azione aziendale di completare il proprio percorso. Molti sviluppatori configurano webhook Stripe, RLS Supabase ed eventi GA4 la sera prima del lancio perché in precedenza hanno verificato soltanto che la pagina fosse visibile.

Prima del lancio vanno controllate queste interfacce:

Modulo	Interfaccia da chiudere	Omissione comune	Azione di verifica
Ingresso del sito	Pagine accessibili, route senza 404, asset caricati e build monitorate	Quota Cloudflare Free superata; nessuno legge i log	Aprire home e prezzi su dispositivi reali; controllare le build di Cloudflare Pages
Forma del prodotto	Forma definita — contenuti, strumento o SaaS — e prezzo spiegato	Presentazione senza prezzo o acquisto; Stripe Product assente	Controllare Products/Prices in Stripe Dashboard e il prezzo su /pricing
Flusso di pagamento	Checkout Session, webhook, accesso dopo il pagamento, errori/annullamento e sincronizzazione	Webhook assente; pagamento senza accesso; rimborso non sincronizzato	Completare un pagamento di test; controllare log webhook e tabella degli abbonamenti
Sistema utenti	Login, RLS, stato dell’abbonamento e permessi diversi per utenti gratuiti e paganti	Solo login; ogni utente vede contenuti a pagamento	Controllare subscriptions in Supabase e verificare RLS con un account gratuito
Eventi dati	GA4/GSC, 5–8 eventi, tracciamento di pagamento/registrazione/prova e avvisi di errore	Solo page_view; nessun evento per clic di acquisto o registrazione	Verificare gli eventi in GA4 DebugView e query/pagine in GSC Performance
Ritorno del feedback	Invio, passaggio a un’attività e risposta di assistenza	Il modulo manda solo email, senza bacheca o seguito	Inviare feedback e controllare che raggiunga bacheca o coda email
Confine dell’automazione	Soglie Webhook/API/Cron, avvisi e rollback	L’automazione fallisce in silenzio; il limite si scopre dopo	Controllare l’uso di Workers; impostare soglie e monitoraggio
Controllo dei costi	Uso Cloudflare/Supabase registrato, quote note e piano di upgrade	Progetto Supabase Free sospeso; Workers supera la quota	Controllare consumo e attività; registrare i trigger di upgrade

Ogni voce richiede un’operazione reale, non soltanto la lettura dei file nel repository. Prima del lancio completa almeno un pagamento, una verifica di login e permessi, un controllo degli eventi e l’invio di un feedback.

Livello di ingresso: stack minima di deploy e relativi confini

L’ingresso può iniziare con un sito statico o un framework leggero, ma build, file e funzioni dinamiche devono entrare nel budget. Cloudflare Pages e Astro riducono la manutenzione iniziale; le quote gratuite, però, non sono una promessa architetturale.

Tabella di scelta dello stack

Forma del prodotto	Stack consigliato	Costo di build	Costo dinamico	Scenario
Sito di contenuti	Astro / Hugo / Hexo	Cloudflare Pages Free: 500 builds/month, 20.000 files, asset da 25 MiB	Pages Functions conteggiate in Workers	Blog, documentazione, contenuti SEO e presentazione
Strumento	Astro + chiamata API	Come sopra	Chiamate API in Workers: 100.000 requests/day	Strumento a pagina singola, ricerca, calcolo e visualizzazione
SaaS	Astro + Supabase	Come sopra	Workers + Supabase Edge Functions	Multiutente, abbonamenti, permessi e lettura/scrittura dati

Al 26 luglio 2026, i limiti ufficiali di Cloudflare Pages per il piano Free erano 500 build al mese, timeout di 20 minuti per build, fino a 20.000 file e asset singolo di massimo 25 MiB. Le richieste di Pages Functions rientrano nelle quote Workers; Workers Free include 100.000 richieste al giorno e 10 ms di CPU per invocazione.

Gli asset statici non rendono gratuito l’intero sistema. Un sito con molte immagini, video o download deve considerare anche object storage, CDN, trasformazioni e traffico in uscita.

Non affidarti solo alla generazione massiva con IA

Le linee guida di Google Search sui contenuti con IA generativa consentono di usare l’IA per ricerca e organizzazione di contenuti originali, ma creare su larga scala pagine prive di valore aggiuntivo per l’utente può configurare scaled content abuse. L’ingresso richiede prodotto, feedback e analisi reali, non centinaia di pagine SEO automatiche.

Per le prestazioni puoi consultare Ottimizzazione pratica di Astro 5. Il sistema minimo non deve partire da Lighthouse 100: la pagina deve aprirsi, gli asset caricarsi, la CTA funzionare e qualcuno deve ricevere l’errore di build.

Livello prodotto: contenuti, strumento o SaaS nella prima versione

La forma del prodotto determina la complessità di pagamenti, utenti, dati e automazione. Contenuti, strumento e SaaS sono livelli crescenti, non tre pulsanti equivalenti. La prima versione deve privilegiare tecnologia familiare, pagamento semplice e pochi dati utente.

Tabella di scelta della forma

Forma	Complessità tecnica	Complessità del pagamento	Dati utente	Idoneità alla prima versione
Contenuti	Bassa: statico + CMS + SEO	Bassa: pagamento unico o gratuito	Bassa: email, RSS e commenti	Alta: acquisizione SEO, monetizzazione e test della domanda
Strumento	Media: statico + API + backend leggero	Media: pagamento unico o abbonamento	Media: account leggero e storico d’uso	Media: validare una funzione e il modello di pagamento
SaaS	Alta: autenticazione + database + abbonamento + RLS	Alta: abbonamento, consumo e rimborsi	Alta: multiutente, permessi, abbonamenti e isolamento	Bassa: domanda pagante chiara e stack già padroneggiato

Criteri di scelta

La decisione dipende da tre fattori:

1. Familiarità con lo stack: chi conosce Astro o Hugo può validare rapidamente i contenuti; strumenti e SaaS hanno meno rischio se Supabase o Postgres sono già familiari.
2. Complessità del pagamento: il pagamento unico è di solito più semplice dell’abbonamento, a sua volta più semplice della tariffazione a consumo. La prima versione può usare pagamento unico o raccolta gratuita di contatti.
3. Necessità di dati utente: i contenuti possono richiedere solo email e RSS; uno strumento necessita dello storico; un SaaS richiede identità, permessi, stato dell’abbonamento e isolamento.

La forma del prodotto non è un’identità. Finché un’azione centrale non è stabile, non iniziare da centro account, spazi di team e marketplace di template.

Livello pagamenti: non è un pulsante finale, perché modifica i dati

Il pagamento è il livello più rischioso. Influenza database, utenti, diritti, back office ed email. Anche quando Stripe Checkout incassa, un webhook che non abilita l’accesso, un rimborso non sincronizzato o un abbonamento scaduto che conserva i permessi diventano problemi reali di adempimento.

Passaggi del flusso di pagamento

Il circuito minimo di Stripe comprende:

Passaggio	Oggetto Stripe	Interfaccia obbligatoria	Omissione comune
1. Creare il prodotto	Products	Crearlo in Stripe Dashboard e mostrarlo nella pagina prezzi	/pricing mostra un prezzo, ma Stripe Product non esiste
2. Creare il prezzo	Prices	Impostare importo, valuta, periodo e modello: unico, abbonamento o consumo	Abbonamento senza interval; consumo senza meter
3. Creare Checkout Session	Checkout Session	Impostare line_items, mode, success_url, cancel_url	success_url reindirizza senza verificare il pagamento
4. Configurare webhook	Webhook endpoint	Ricevere checkout.session.completed, invoice.paid, customer.subscription.deleted e altri	Webhook assente; pagamento senza attivazione
5. Eseguire l’adempimento	Logica personalizzata	Attivare l’accesso nel database e inviare conferma	Attivazione manuale senza processo tracciabile
6. Gestire il rimborso	Refunds	Aggiornare l’abbonamento, revocare l’accesso e notificare	Accesso ancora attivo dopo il rimborso
7. Sincronizzare l’abbonamento	Subscriptions	Aggiornare stato a rinnovo, annullamento e scadenza	La scadenza non revoca l’accesso

Tabella di scelta del modello di pagamento

Il modello modifica la struttura dati:

Modello	Effetto sui dati	Gestione degli accessi	Scenario
Pagamento unico	Aggiungere paid_at o purchase_id all’utente	Attivazione unica, permanente o a tempo	Prodotto digitale, corso, template o acquisto di uno strumento
Abbonamento	Creare subscriptions: user_id, stripe_subscription_id, status, current_period_end	Attivazione e revoca periodica con sincronizzazione	Strumento, SaaS e contenuti per membri
Consumo	Creare usage: user_id, meter, amount, timestamp	Abilitare e limitare in base all’uso, con saldo	API, storage e risorse di calcolo

Il modello Products/Prices di Stripe permette di creare un nuovo Price e trasferirgli un lookup key. Cercare il prezzo tramite lookup key evita di fissare il Price ID in più punti, ma la modifica richiede comunque creazione e attivazione del nuovo prezzo secondo la procedura ufficiale.

Adempimento, rimborsi e sincronizzazione richiedono webhook e logica di database. Non dipendere dalla pagina di successo del frontend o da operazioni manuali nel Dashboard. Per approfondire, leggi Scelta del sistema di pagamento per solo founder.

Procedura di verifica dei pagamenti di test

Prima del lancio completa il flusso nell’ambiente di test Stripe:

1. Usa l’ambiente di test in Stripe Dashboard
2. Usa i metodi correnti della documentazione Stripe per successo, rifiuto e autenticazione aggiuntiva
3. Inserisci i dati di test nel Checkout e completa il pagamento
4. Controlla Payments ed Events per confermare gli eventi attesi
5. Controlla subscriptions o il record di accesso nel database
6. Accedi con un account abilitato, poi verifica il confine con un account privo di accesso

Dopo il test controlla separatamente chiavi, webhook endpoint, firma degli eventi e notifiche in produzione.

Livello utenti: identità, permessi e abbonamento sono distinti

Un pulsante di login non chiude il sistema. Il livello minimo distingue identità, permessi, stato dell’abbonamento e confine dei dati. Se ogni utente autenticato legge dati a pagamento, il problema è l’autorizzazione, non il componente di login.

Supabase Auth gestisce password, magic link, OTP, social login e SSO. JWT e RLS del database formano il confine di autorizzazione: l’autenticazione risponde “chi sei”; la policy RLS decide “quali righe puoi leggere o modificare”.

Checklist minima degli utenti

Capacità	Funzione Supabase	Interfaccia obbligatoria	Omissione comune
Autenticazione	Password, magic link, OTP, social e SSO	Login, JWT e accesso ai propri dati	Pulsante di login senza confine di autorizzazione
Permessi	RLS	Ogni utente vede i propri dati; i paganti accedono ai contenuti pagati	RLS disattivata o policy troppo ampia
Sincronizzazione abbonamento	Webhook Stripe → subscriptions	Aggiornare successo, rinnovo, annullamento e scadenza	Stato presente soltanto in Stripe
Confine dei dati	RLS policy	Gli utenti vedono le proprie righe; gli amministratori usano un percorso separato	Isolamento non testato; dati di altri utenti visibili

I progetti Supabase usano Postgres come base, insieme ad Auth, Storage, Realtime ed Edge Functions. Lo stato dell’abbonamento va sincronizzato da un backend affidabile; il frontend non può decidere da solo l’accesso a pagamento.

Verifica RLS con almeno due account, uno abilitato e uno no. Controlla anche che service role e altre chiavi privilegiate non siano esposte nel browser.

Livello dati: 5–8 eventi aziendali, non un solo script statistico

Installare GA4 o uno script non completa il livello dati. Il sistema minimo richiede 5–8 eventi che cambiano le decisioni, coprendo visita, clic, azione centrale, registrazione, pagamento, errore e feedback.

Elenco degli eventi aziendali

Evento	Nome evento GA4	Momento	Uso nell’analisi
Visita della pagina	page_view	Caricamento pagina	Ingresso dei contenuti e origine SEO
Clic sul pagamento	begin_checkout o evento personalizzato	Clic su acquisto o abbonamento	Funnel e rendimento della pagina prezzi
Registrazione completata	sign_up	Fine registrazione	Conversione e acquisizione
Inizio prova	Evento personalizzato trial_start	Inizio prova o esperienza gratuita	Conversione della prova e miglioramento
Pagamento completato	purchase	Il backend conferma il pagamento	Ricavi e miglioramento del flusso
Errore o crash	Evento personalizzato error_occurred	Errore frontend, API o azione centrale	Stabilità e diagnostica
Feedback inviato	Evento personalizzato feedback_submit	Invio di feedback o problema	Tasso e classificazione dei feedback

GA4 consente di contrassegnare le azioni importanti come key event. Realtime e DebugView servono a verificare la raccolta; l’analisi effettiva deve controllare anche parametri, origine e deduplicazione.

Procedura di analisi dei dati

Esegui l’analisi almeno una volta a settimana:

1. GA4: controllare gli eventi aziendali: verifica la raccolta in DebugView e osserva il percorso tra visita, registrazione, prova e pagamento.
2. GSC: controllare query e pagine: nel report Performance osserva clic, impressioni, CTR, posizione media, query e pagine.
3. Analytics di prodotto: decidere il livello di dettaglio: aggiungi PostHog o un’alternativa quando GA4 non mostra cosa ha fatto un singolo utente, quante volte o dove ha abbandonato.

GSC, log e avvisi sono utili anche prima dei ricavi. Espongono query, attrito nella pagina dei prezzi, errori dell’azione centrale e problemi ricorrenti. Se la raccolta parte con il primo cliente, le cause precedenti sono già perse.

Livello automazione: cosa conviene il primo giorno e cosa aumenta il rischio

Alcune automazioni eliminano ripetizioni sicure; altre amplificano il danno quando falliscono. Gli strumenti di coding con IA accelerano lo sviluppo, ma non verificano pagamenti, permessi, sicurezza o dati aziendali.

Coding agent come Codex aiutano a comprendere repository, implementare, revisionare, eseguire debug, testare e migrare. Collaborano allo sviluppo. Adempimento, confini di accesso, segreti di produzione, avvisi e feedback restano sotto responsabilità umana.

Tabella dei confini dell’automazione

Automazione	Utile dal primo giorno	Rischio aggiunto	Soglia d’uso
Deploy	Build e deploy dopo Git push	Quota superata; errore senza notifica	Build e timeout di Pages
Notifica	Pagamento → accesso → conferma	Webhook senza retry; notifica e accesso divergono	Richieste Workers, CPU e tentativi
Backup	Esportare dati critici; attivare backup nel piano a pagamento	Free non include backup automatici; export fallito invisibile	Dimensione database, storage e ripristino
Analisi periodica	Esportare GA4/GSC e generare report	Frequenza eccessiva; quote e ritardi ignorati	Quota API GA4/GSC
Orchestrazione complessa	Rendere osservabile pagamento → accesso → email → CRM	Un errore interrompe la catena; senza idempotenza o rollback	Errori per fase, retry e dead letters
Dipendenze multiple	Collegare Webhook, API, Cron, email e CRM	Latenze diverse; assenza di log unificati	Richieste dinamiche, code e API esterne

Soglie per Webhook, API e Cron

Webhook, API leggere e Cron possono funzionare in Cloudflare Workers, ma i limiti attuali entrano nel budget:

• Workers Free: 100.000 requests/day e 10 ms CPU/invocation.
• Workers Paid: da 5 USD al mese per account; Standard include 10M requests/month e 30M CPU ms/month, poi addebita il consumo eccedente.

Asset statici e richieste dinamiche seguono regole diverse. Monitora insieme richieste, CPU, retry, log, KV, Queues, R2 e prodotti collegati, non un solo numero “gratuito”.

Avvisi di deploy, conferma del pagamento, instradamento del feedback e riepiloghi periodici sono buone automazioni iniziali. Rimborsi automatici, cancellazione dei dati di produzione, modifiche ai permessi, messaggi di massa e prezzi devono mantenere l’approvazione umana finché audit, idempotenza e rollback non sono verificati.

Soglie di costo: la quota gratuita non è una promessa architetturale

Una quota gratuita è un budget iniziale, non una promessa. I limiti di Cloudflare e Supabase dipendono da richieste dinamiche, CPU, storage, egress, build, log e modalità d’uso. Non garantiscono “gratis per sempre” né un numero fisso di utenti.

Tabella di costi e limiti

Servizio	Quota gratuita	Inizio del pagamento o upgrade	Rischio di cambiamento	Limite da monitorare
Cloudflare Pages	500 builds/month, 20.000 files, asset da 25 MiB e timeout di 20 minuti	Aumentare i limiti Pages con il piano Cloudflare appropriato	Quote e piani possono cambiare	Build, file e timeout
Cloudflare Workers	100.000 requests/day, 10 ms CPU/invocation; asset statici gratuiti	Paid da 5 USD/account/month, con 10M requests e 30M CPU ms	Prezzo, CPU, richieste e prodotti cambiano	Richieste, CPU, retry e avvisi
Supabase	50.000 MAU, database da 500 MB, storage da 1 GB, egress da 5 GB, 2 progetti Free; possibile sospensione dopo una settimana di inattività	Pro a 25 USD/month con 10 USD di compute credits	Progetti, calcolo, traffico e sicurezza cambiano	MAU, database, storage, egress e attività

Questi numeri sono stati verificati il 26 luglio 2026 sui limiti di Cloudflare Pages, sui prezzi di Workers e sui prezzi di Supabase. Consulta di nuovo le pagine ufficiali al lancio.

Un progetto Supabase Free inattivo può essere sospeso dopo una settimana e Free non include backup automatici. “Il progetto si apre” non è un test di salute. Verifica attività, esportazione, ripristino e trigger di upgrade.

Consulta anche l’elenco dei limiti gratuiti di Cloudflare e il confronto dei piani Cloudflare.

Riepilogo

Il sistema minimo vitale di un solo founder non è un elenco corto di strumenti. Ogni azione importante necessita di ingresso, risultato e percorso d’errore: la persona arriva, riceve il prodotto, paga, ottiene accesso, produce dati, invia feedback e riceve assistenza negli incidenti.

La prima versione non deve essere perfetta, ma deve poter essere verificata. Tieni launch-checklist.md accanto al repository e percorri pagamenti, permessi, eventi, feedback e incidenti come un utente reale. Frontend, backend, deploy, database, pagamenti e analytics potranno crescere senza ricostruire tutto per una consegna dimenticata.