--- title: "Sviluppo di web app, SaaS e MVP su misura — Dardo" description: "Sviluppo di web app, SaaS e MVP: account e ruoli, pagamenti verificati sul server, area admin e domini dei clienti, per una prima versione ben definita." url: "https://dardo.studio/it/servizi/sviluppo-web-app/" language: "it" translations: {"en":"https://dardo.studio/en/services/web-app-development/","es":"https://dardo.studio/es/servicios/desarrollo-de-software-a-medida/","fr":"https://dardo.studio/fr/services/developpement-application-web/","de":"https://dardo.studio/de/leistungen/webapp-entwicklung/","pt":"https://dardo.studio/pt/servicos/desenvolvimento-de-aplicativos-web/","nl":"https://dardo.studio/nl/diensten/web-app-ontwikkeling/","sv":"https://dardo.studio/sv/tjanster/webbapputveckling/","pl":"https://dardo.studio/pl/uslugi/tworzenie-aplikacji-webowych/","uk":"https://dardo.studio/uk/services/web-app-development/","ru":"https://dardo.studio/ru/services/web-app-development/","ar":"https://dardo.studio/ar/services/web-app-development/","hi":"https://dardo.studio/hi/services/web-app-development/","th":"https://dardo.studio/th/services/web-app-development/","ja":"https://dardo.studio/ja/services/web-app-development/","ko":"https://dardo.studio/ko/services/web-app-development/","zh-Hans":"https://dardo.studio/zh-Hans/services/web-app-development/","zh-Hant":"https://dardo.studio/zh-Hant/services/web-app-development/"} updated: "2026-10-08" --- # Sviluppo di web app, SaaS e MVP Dardo sviluppa web app, prodotti SaaS e MVP per founder e aziende che hanno bisogno di un software in cui i clienti accedono, pagano e di cui possono fidarsi, non di un sito vetrina. Definiamo la prima versione attorno a un unico flusso di lavoro centrale, poi la progettiamo, la sviluppiamo, la testiamo e la lanciamo con account, permessi, pagamenti, un'area admin e analytics, su codice e account di tua proprietà. Di Redazione Dardo · Aggiornato il 8 ott 2026 · 10 min di lettura [Scrivici su WhatsApp](https://wa.me/573163373216?text=Ciao%20Dardo%2C%20vorrei%20una%20proposta%20per%3A%20Sviluppo%20di%20web%20app%2C%20SaaS%20e%20MVP) ## 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. __Cosa deve contenere la prima versione di un MVP?__ | Modulo | Cosa richiede | Da decidere prima di sviluppare | | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | Account e ruoli | Registrazione, accesso, recupero e un controllo del ruolo a ogni richiesta al server | Quali ruoli esistono e una persona può appartenere a più organizzazioni? | | Inviti al team | Link d'invito a scadenza, numero di posti, trasferimento della proprietà, rimozione che revoca subito l'accesso | Chi può invitare e cosa succede ai dati di un membro rimosso? | | Fatturazione e piani | Checkout ospitato o abbonamenti, callback verificati, limiti dei piani applicati dal server | Cosa include ogni piano e cosa succede se un pagamento fallisce? | | Prenotazioni e calendario | Regole di disponibilità, fusi orari, margini tra appuntamenti, protezione dalle doppie prenotazioni, promemoria, riprogrammazione | Chi imposta la disponibilità e lo slot resta bloccato mentre il cliente paga? | | Richieste e pipeline di lead | Modulo protetto dallo spam, stati da nuovo a vinto o perso, assegnazione, fonte, registro del consenso | Quali stati usa davvero il tuo team e dove va un lead dopo? | | Admin e reportistica | Ricerca, storico dei record, correzioni manuali, esportazioni | Quali numeri controlla il team ogni settimana e chi può modificare i record? | | Domini personalizzati | Configurazione dell'hostname, verifica DNS, stato del certificato, controlli sul piano | Quali piani includono un dominio e quali limiti dell'host si applicano? | | Audit log | Registro append-only di chi ha cambiato cosa e quando | Quali azioni devono poter essere tracciate dai tuoi clienti o dai revisori? | | Notifiche | Messaggi via email e in-app, template, registro di consegna, preferenze dell'utente | Quali eventi notificano chi e quali possono essere disattivati? | ## 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 **Da cosa dipende il costo di una web app o di un MVP?** Il costo dipende dal numero di ruoli, dalla complessità del flusso di lavoro principale, dai pagamenti, dalle integrazioni e da quanti dati esistenti vanno migrati. Permessi e stati contano più del numero di schermate: una schermata con cinque ruoli e un passaggio di approvazione richiede più lavoro di cinque schermate in sola lettura. Quotiamo un ambito scritto dopo la fase di definizione, non una tariffa per singola funzionalità. **Quanto tempo serve per realizzare una prima versione?** Dipende da quanto è definito il flusso di lavoro, da quanto rapidamente arrivano decisioni e contenuti e dal fatto che terze parti, come un provider di pagamento o il team IT di un cliente, debbano approvare l'accesso. La proposta fissa delle milestone, a partire da una porzione funzionante del flusso di lavoro principale. La data del rilascio completo viene stabilita una volta accettata quella porzione. **Dardo può rilevare un codebase esistente?** Sì, dopo un audit. Esaminiamo repository, dipendenze, modello dei dati, controlli di accesso, rilascio e chi controlla ciascun account, poi riferiamo cosa può restare, cosa va corretto per primo e se ha più senso riparare o riscrivere. Non promettiamo di mantenere o sostituire un codebase prima di averlo letto. **Sviluppate app native per iOS e Android?** No. Dardo lavora per il web, comprese le web app installabili che si aprono da un'icona nella schermata Home. Quando un prodotto dipende da funzioni del dispositivo che il browser non espone, dalla distribuzione negli app store o da un uso offline intensivo, un'app nativa è più adatta e ve lo diremo. La web app e la sua API possono comunque fare da backend per un team nativo. **Di chi sono il codice e gli account?** Vostri. Repository, hosting, database, dominio, provider di pagamento e account di analytics vengono creati a vostro nome o trasferiti alla consegna, e la proposta elenca ogni dipendenza con licenza che non può essere trasferita. Dardo conserva solo l'accesso che ci concedete per il supporto. **Di cosa avete bisogno da noi?** Di un decisore che sappia rispondere alle domande sull'ambito entro pochi giorni, dell'accesso ai sistemi a cui il prodotto deve collegarsi e di esempi reali dei dati e dei documenti usati dal flusso di lavoro. Aprite presto l'account del provider di pagamento a nome della vostra azienda, perché i provider verificano l'attività prima di abilitare i pagamenti live. **Cosa succede dopo il lancio?** La proposta può includere un periodo di supporto per bug, monitoraggio e piccole modifiche mentre arrivano i primi utenti reali. Dopo, lo sviluppo successivo si concorda come ambito mensile o come nuovo progetto. Gli aggiornamenti di sicurezza e delle dipendenze non sono facoltativi, quindi in entrambi i casi serve un responsabile indicato per nome. ## Dal blog - [Domini personalizzati per SaaS: far usare ai clienti il proprio dominio con Cloudflare for SaaS](https://dardo.studio/it/blog/domini-personalizzati-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. ## Fonti e approfondimenti Le fonti di questa pagina, con ulteriori dettagli dagli editori originali. - [OWASP Top 10:2025, A01 Broken Access Control](https://top10.owasp.org/2025/A01%5F2025-Broken%5FAccess%5FControl) · top10.owasp.org - [Cloudflare for SaaS: piani e limiti degli hostname personalizzati](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/plans/) · developers.cloudflare.com - [Cloudflare for SaaS: per iniziare (target CNAME e record A)](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/) · developers.cloudflare.com - [Cloudflare for SaaS: metodi di convalida dei certificati](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/issue-and-validate/validate-certificates/) · developers.cloudflare.com - [Cloudflare: autorità di certificazione](https://developers.cloudflare.com/ssl/reference/certificate-authorities/) · developers.cloudflare.com - [Vercel: limiti (domini per progetto)](https://vercel.com/docs/limits) · vercel.com - [Netlify: aggiungere un alias di dominio](https://docs.netlify.com/manage/domains/configure-domains/add-a-domain-alias/) · docs.netlify.com [Dardo](https://dardo.studio/it/) · [Servizi](https://dardo.studio/it/servizi/) · Web app e SaaS ## Lavori e studi correlati [![Sito superame.lol, un progetto di Dardo](https://dardo.studio/work/superame-1.webp?v=34a51b35f537) · In pratica / Lavori selezionati · **superame.lol** · Vedi il progetto](https://dardo.studio/it/lavori/superame/) ## Pianifica la tua prima versione Descrivi il flusso di lavoro che i tuoi clienti o il tuo staff devono completare e chi vi partecipa. Ti rispondiamo con le domande che determinano l'ambito e ti diciamo chiaramente se esiste già uno strumento acquistabile che fa al caso tuo. [01 · **Esamina i lavori pertinenti** · superame.lol](https://dardo.studio/it/lavori/superame/) · [02 · **Confronta l'ambito affine** · Product design](https://dardo.studio/it/servizi/product-design-ux-ui-web-app-saas/) · [03 · **Parla del tuo brief** · Richiedi una proposta dettagliata nella tua lingua](https://dardo.studio/it/contatti/?service=web-app-development) ## Continua a esplorare. - [![superame.lol: anteprima del sito](https://dardo.studio/_astro/01M4H711Q11QCMQDA10WE4A1K7_ZrTSRU.webp) · Caso studio · **superame.lol: case study di web design**](https://dardo.studio/it/lavori/superame/) - [Servizio · **Product design e UX/UI per web app e SaaS**](https://dardo.studio/it/servizi/product-design-ux-ui-web-app-saas/) - [Servizio · **Sviluppo di portali clienti su misura**](https://dardo.studio/it/servizi/sviluppo-portale-clienti/) - [Servizio · **Design di data visualization e interfacce per dashboard**](https://dardo.studio/it/servizi/data-visualization-design/)