Sviluppo di web app, SaaS e MVP

Cosa include un progetto di web app o MVP#

Costruiamo l'incarico attorno al brief reale. La proposta indica quali di questi deliverable sono inclusi, chi fornisce i materiali necessari e come viene approvato ciascuno di essi.

• Ambito della prima versione: flusso centrale, ruoli e cosa può aspettare
• Schermate chiave progettate con stati vuoti, di caricamento e di errore
• Modello dei dati, regole di accesso lato server e test che cercano di aggirarle
• Account, ruoli e inviti al team
• Pagamenti o abbonamenti confermati da callback verificati del provider
• Area admin, eventi di analytics di prodotto e monitoraggio degli errori
• Rilascio, documentazione e consegna del repository e degli account

Prima la web app, il sito web o il design del prodotto?#

Scegli questa soluzione quando clienti o collaboratori devono accedere e svolgere attività nel prodotto: acquistare, prenotare, inviare, approvare o gestire qualcosa. Se ti serve un sito che racconti e venda la tua offerta, è più adatto lo sviluppo web. Se il flusso di lavoro non è ancora definito, parti dal Product Design e sviluppa solo dopo aver testato le schermate chiave con gli utenti.

Come si costruisce una prima versione#

Partiamo da una fase di definizione: utenti e ruoli, l'unico flusso di lavoro che la prima versione deve completare, i dati generati da ogni passaggio e le decisioni che cambiano i costi, come pagamenti, integrazioni e permessi. Il risultato è un documento di scope scritto, schermate chiave cliccabili e un piano di rilascio che indica cosa viene rimandato.

Poi sviluppiamo a cicli brevi su un ambiente di staging che puoi usare. Il primo traguardo è una fetta sottile del flusso centrale funzionante da un capo all'altro, con accesso reale e regole sui dati reali, prima di completare le altre schermate. Il lancio comprende monitoraggio in produzione, un piano di rollback e la consegna del repository e degli account di hosting, database, pagamenti e analytics a tuo nome.

Cosa deve contenere la prima versione di un MVP?#

Una prima versione deve avere tutto ciò che serve a un utente reale per completare un flusso di lavoro, e nulla che conti solo su una scala che non hai ancora raggiunto. In pratica sono cinque cose: account con i ruoli richiesti dal flusso, il flusso centrale stesso, un'area admin che permetta al tuo team di vedere e correggere i dati senza uno sviluppatore, i pagamenti se il modello di business prevede di incassare fin dal primo giorno, e eventi di analytics che mostrano dove gli utenti si fermano.

Rimanda ciò che si può fare a mano o acquistare più avanti: un'app mobile nativa, il single sign-on per clienti enterprise, una matrice di permessi configurabile, una seconda integrazione, la chat in-app e report che nessuno ha chiesto. Ogni voce rimandata ha comunque una riga nello scope, così il modello dei dati lascia spazio per aggiungerla.

La maggior parte dei prodotti è composta da moduli familiari. Due meritano una nota: prenotazioni e calendario, e una pipeline di lead per una piccola impresa che oggi tiene traccia delle richieste a mano. Entrambi sembrano semplici e nascondono decisioni su fusi orari, stati e responsabilità che costa meno chiarire prima, su carta.

Quale stack usa Dardo e quando ne sceglie uno diverso?#

Il nostro default è TypeScript da cima a fondo: Astro per pagine renderizzate sul server e componenti interattivi, Cloudflare Workers per hosting e API, Cloudflare D1 o Postgres per i dati e PostHog per analytics ed esperimenti. Superame funziona con Astro e la sua classifica è salvata su Neon Postgres. Un solo linguaggio e un solo target di deploy rendono un piccolo prodotto semplice da gestire e da consegnare.

Scegliamo diversamente quando il prodotto lo richiede. Un'interfaccia densa che resta aperta tutto il giorno può giustificare un'applicazione React lato client, come nel prototipo di Shiimain. Anche job di lunga durata, elaborazione pesante di dati o un team interno che lavora già con un altro framework cambiano la risposta. Se saranno i tuoi sviluppatori a gestire il codice dopo il lancio, di solito vince il loro stack.

Il controllo degli accessi è la prima cosa che testiamo. La OWASP Top 10:2025 mantiene Broken Access Control al primo posto e riporta che ogni applicazione testata presentava una qualche forma di questa vulnerabilità. Applichiamo i permessi sul server a ogni richiesta, neghiamo per impostazione predefinita, limitiamo ogni query all'organizzazione dell'utente connesso e scriviamo test automatici che cercano di leggere i dati di un altro cliente.

Come dovrebbero funzionare i pagamenti in una web app?#

Il provider di pagamento conferma un pagamento sul server; il browser che torna dal checkout non lo fa mai. Superame, una classifica pubblica di progetti tra i lavori pubblicati di Dardo, mostra questo schema. Gli acquirenti pagano sul checkout ospitato di Dodo Payments, quindi i dati della carta non raggiungono mai l'app. Il provider invia poi una callback firmata, e il server verifica la firma e controlla i dettagli del pagamento prima di aggiungere il credito.

Rimborsi e contestazioni seguono lo stesso percorso. Ogni evento del provider viene applicato una sola volta, quindi una callback che arriva due volte, in ritardo o fuori ordine non può aggiungere o togliere il credito due volte. Superame non pubblica dati di adozione o di ricavi; è una prova di come è costruita la logica dei pagamenti, non delle vendite.

• Un acquirente che chiude la scheda prima del reindirizzamento riceve comunque il credito quando arriva la callback.
• Una callback ripetuta o falsificata viene rifiutata.
• Un rimborso o una contestazione annulla esattamente ciò che il pagamento originale aveva concesso.
• I limiti del piano vengono verificati sul server, non soltanto nascosti nell'interfaccia.
• Le chiavi di test e quelle live sono segreti separati, mai salvati nel repository.

Lascia che i tuoi clienti usino i propri domini#

I clienti SaaS B2B spesso vogliono il prodotto sul proprio indirizzo, ad esempio portal.theircompany.com. Cloudflare for SaaS lo gestisce con i custom hostname: i piani Free, Pro e Business ne includono 100, ogni hostname aggiuntivo costa $0.10 e il massimo è 50,000. I custom hostname wildcard sono disponibili solo con Enterprise.

Il tuo cliente aggiunge un record CNAME che punta al tuo target. Usare un record A per puntare a quel target, cosa necessaria per un dominio root, non è supportato per impostazione predefinita, e il proxying dell'apex è un componente aggiuntivo Enterprise, quindi la maggior parte dei clienti dovrebbe usare un sottodominio. I certificati vengono convalidati via HTTP, TXT o email, oppure con Delegated DCV, un record una tantum che permette a Cloudflare di rinnovarli automaticamente. Sono emessi da Let's Encrypt, Google Trust Services o SSL.com.

Conta altrettanto il lavoro di prodotto intorno: solo i piani a pagamento possono collegare un dominio, una schermata di onboarding mostra il record esatto da aggiungere, lo stato di verifica spiega in modo chiaro gli stati in sospeso e di errore, e il monitoraggio avvisa il tuo team quando un certificato non può essere rinnovato perché un cliente ha cambiato il proprio DNS. Altri host impongono limiti diversi: Vercel consente 50 domini per progetto su Hobby e illimitati su Pro ed Enterprise, con limiti soft di 100,000 e 1,000,000; Netlify consiglia di non superare 50 alias di dominio per sito.

Domande prima di scegliere#

Dal blog#

• Domini personalizzati per SaaS: far usare ai clienti il proprio dominio con Cloudflare for SaaS

  Fai usare ai clienti il loro dominio sul tuo SaaS con Cloudflare for SaaS: come funziona la validazione, quanto costa a ottobre 2026 e dove si inceppa.