Sviluppo database-first:progetta prima di fare il prompt

Lo sviluppo database-first significa progettare il database prima di scrivere una sola riga di codice applicativo. Le due settimane che dedichi a progettare il sistema prima di costruirlo ti faranno risparmiare due mesi di refactoring durante la build. Non è un'ipotesi: è un calcolo dimostrato in ogni codebase che abbia mai visto, compresa la mia.

Le due settimane più importanti nella costruzione di FIKR Space sono state quelle in cui ho progettato lo schema del database prima di scrivere codice applicativo. La maggior parte delle persone annuisce a questa frase e poi la ignora. Questa è la versione pratica: le tre cose che "progettare l'architettura" significa davvero, e la timeline di sviluppo che ne segue una volta fatto.

Sviluppo database-first: perché la tentazione è la trappola

Sarai tentato, appena finita la validazione, di aprire Claude o Cursor e iniziare a costruire. Vorrai la dopamina del codice che si accumula. Vorrai mostrare a tua moglie o a tuo marito uno screenshot a fine weekend. Resisti.

Iniziare a scrivere codice prima che il database sia progettato è l'errore madre: ogni altra trappola della costruzione ne discende. Il primo giorno ti senti produttivo perché l'AI genera schermate, ma la base sotto è fluida, e ogni settimana che la base si sposta, tutto ciò che c'è sopra va rifatto. Quel circolo vizioso di rielaborazione sempre più rapido è esattamente il modo in cui la trappola del vibe coding si chiude attorno a chi si sentiva inarrestabile alla prima settimana.

Passo 1: progetta il database, su carta

Elenca ogni entità del tuo prodotto. Utenti. Aziende. Abbonamenti. Quali che siano i sostantivi centrali. Poi elenca le relazioni: un utente appartiene a un'azienda, un'azienda ha molti utenti, un abbonamento appartiene a un'azienda e traccia l'utilizzo.

Disegnali su carta. Sì, carta. Il gesto di disegnare ti fa pensare ai casi limite che un progetto solo mentale ti farebbe perdere. Quando riquadri e frecce smettono di cambiare, hai uno schema. Poi descrivi chiaramente le entità a Claude, e ti scriverà l'SQL vero e proprio in venti minuti. Ora hai le tue fondamenta.

Passo 2: definisci i confini dei servizi

Quali sono le operazioni principali del tuo sistema? Registrarsi. Elaborare un pagamento. Generare un report. Inviare una notifica. Ognuna è un servizio: un pezzo autonomo del sistema con un compito definito. Definisci input e output di ogni servizio prima di scrivere il servizio.

Sembra burocratico. Non lo è. È la differenza tra un sistema che può evolvere e uno che si calcifica dopo tre mesi.

Passo 3: percorri i flussi utente

Ripercorri le tre cose più importanti che un utente farà con il tuo prodotto: registrarsi, compiere la prima azione di valore, rinnovare l'abbonamento. Abbozza ogni flusso come sequenza di schermate o interazioni: non progettare ancora le schermate, solo la sequenza. Stai cercando i punti in cui il flusso si rompe, o in cui hai dato per scontato qualcosa che non sarà vero.

Quando database, servizi e flussi hanno tutti senso su carta, e ce l'hanno ancora dopo averli riguardati con occhi freschi il giorno dopo, hai un'architettura. Ora puoi costruire.

Il libroThe Solopreneur RevolutionLuis Gonçalves su come costruire un'attività da solopreneur con l'IA mentre sei ancora dipendente.Scopri il libro →

La timeline di otto settimane che ne segue

Partire dall'architettura non è più lento. È ciò che rende veloce la parte veloce. Ecco il calendario che sblocca, con da quattro a otto ore a settimana di lavoro concentrato:

Entro la fine della settimana sei, il prodotto ha i suoi tre o quattro flussi principali funzionanti: registrarsi, fare la cosa principale, essere fatturati, tornare domani e rifarla. È ciò che una persona sola può fare nel 2026 e che dieci persone non riuscivano a fare nel 2020 a nessun prezzo, e ognuna di quelle funzionalità settimanali parte da un brief scritto, non da un prompt speranzoso. Questo è il metodo PRP, e funziona solo perché l'architettura sotto ha smesso di muoversi.

Non lasciare che sia l'AI l'architetto

Claude è un esecutore brillante e un architetto mediocre. Chiedigli "questa deve essere una tabella separata o una colonna JSON?" e ti darà una risposta: di solito va bene, a volte è sbagliata, ogni tanto è ottima. Il problema è che non hai modo di valutare in quale caso ti trovi se non hai un tuo gusto architetturale. Sviluppalo deliberatamente: guarda come altri prodotti strutturano i propri sistemi, ragiona sui compromessi su carta e metti per iscritto l'architettura prima di chiedere a Claude di implementarla.

Le decisioni architetturali sono tue. Le decisioni di implementazione sono di Claude. Mantieni quel confine e la codebase migliora nel tempo; sfocalo e la codebase si deteriora.

Se sei a questo punto adesso, ecco la tua settimana: dedica tre sere a entità e relazioni. Disegna lo schema su carta. Rifinisci. Fai generare l'SQL a Claude. Verificalo percorrendo i tuoi tre flussi utente più importanti per vedere se lo schema li supporta in modo pulito. Non scrivere ancora codice applicativo. Entro domenica sera hai uno schema di cui sei sicuro e un elenco delle quattro-sei funzionalità principali che costruirai nelle sei settimane successive. Noioso. Lento. Vale ogni ora.

12 settimaneLa carriera aziendale non è mai stata il pianoCandidati al Solopreneur Accelerator.Candidati ora →

Domande frequenti

Che cos'è lo sviluppo database-first?

Costruire il modello dei dati prima di qualsiasi codice applicativo: elenchi le entità e le relazioni del tuo prodotto, le rifinisci su carta finché non smettono di cambiare, e solo allora generi lo schema e inizi a costruire le funzionalità. Il database è la fondazione: tutto il resto ci poggia sopra, quindi deve smettere di muoversi per primo.

Quanto tempo dedicare all'architettura prima di scrivere codice?

Due settimane: database, confini dei servizi e flussi utente. Quelle due settimane ti fanno risparmiare due mesi di refactoring durante la build, perché le funzionalità costruite su una base stabile non vanno rifatte ogni volta che la base si sposta.

L'AI può progettare il mio database al posto mio?

L'AI può scrivere lo schema: descrivi chiaramente le entità e Claude produce l'SQL in venti minuti. Ma non dovrebbe prendere le decisioni di progetto. Claude è un esecutore brillante e un architetto mediocre: entità, relazioni e compromessi sono scelte tue, da fare prima del prompt.

Non sono tecnico: posso davvero progettare uno schema?

Sì, perché la parte difficile non è tecnica. È elencare i sostantivi del tuo business (utenti, aziende, abbonamenti) e come si relazionano, cosa che conosci meglio di qualsiasi sviluppatore. Riquadri e frecce su carta. Quando smettono di cambiare, il progetto è fatto e l'AI si occupa di tradurlo in SQL.