App vs ecosistema:decidi prima di progettare il database

App vs ecosistema è la domanda a cui rispondere prima di progettare una sola tabella del database: stai costruendo un'app o un ecosistema? Un'app serve un tipo di utente che svolge un solo compito. Un ecosistema serve più tipi di utenti i cui dati si collegano e scorrono tra loro. La risposta cambia tutto del tuo database (la progettazione di un ecosistema è circa 10 volte più complessa) ed è molto meglio saperlo prima che le fondamenta vengano gettate, non dopo.

È la domanda a cui ho risposto prima di scrivere qualsiasi codice per la mia piattaforma, ed è il motivo per cui il database ha le dimensioni che ha. Ecco come porla nel modo giusto, a cosa ti impegna ciascuna risposta e l'esercizio che fa emergere la verità in venti minuti.

La domanda che decide l'intero database

I database sono fondamenta, e le fondamenta prendono forma da ciò che ci starà sopra. Un capanno da giardino e un condominio richiedono entrambi il calcestruzzo, ma nessuno getta la platea di un capanno e poi decide di aggiungere dodici piani. Il software è uguale: la forma del tuo modello dati è stabilita dalla versione più ambiziosa di ciò che stai costruendo, ed è l'unica parte del tuo prodotto che è davvero dolorosa da cambiare in seguito. (Non sai nemmeno cos'è un modello dati? Parti da i database spiegati ai fondatori non tecnici.)

Quindi il primo atto di progettazione non è disegnare tabelle. È decidere cosa stai davvero costruendo. Non le funzionalità: la visione.

Come appare "solo un'app"

Un'app ha un tipo di utente che svolge un solo compito. Un time tracker. Un generatore di fatture. Un costruttore di abitudini. Il suo database è piacevolmente piccolo: una tabella utenti, una tabella progetti, una tabella task, fatto. Semplice.

Non c'è niente di sbagliato in questo. Se la tua visione è davvero uno strumento mirato per un solo pubblico, un database piccolo e pulito è un punto di forza: più veloce da costruire, più facile da ragionare, più economico da mantenere. L'errore non è costruire un'app. L'errore è costruire le fondamenta di un'app sotto l'ambizione di un ecosistema.

Come appare un ecosistema

Quando ho iniziato la mia piattaforma, non mi sono seduto per costruire "un'app". Mi sono seduto per costruire un ecosistema. La visione: una piattaforma dove le startup gestiscono l'intera operatività, gli acceleratori gestiscono i propri programmi e portafogli, i VC monitorano il deal flow e gli investimenti, e gli affiliati promuovono e guadagnano, tutti connessi, tutti in dialogo tra loro.

Quel solo paragrafo ha trasformato il database. Invece di una tabella utenti, mi servivano organizzazioni di tipi fondamentalmente diversi (startup, acceleratori, VC, affiliati) con utenti collegati a esse in ruoli diversi. Invece delle tabelle di un solo prodotto, mi servivano dieci prodotti (OS, HUB, CAP, Money, People, Score, Pitch, Accelerator, Affiliates, VC) che condividono dati che scorrono tra loro: la startup che gestisce un fondatore è la stessa che un acceleratore segue e un VC valuta. Relazioni tra tutti, ovunque.

Ecco perché la piattaforma gira su 964 tabelle. Non perché volessi la complessità, ma perché la visione l'ha richiesta. Il database di un ecosistema non è un database di app più grande; è un tipo diverso di oggetto, come la rete stradale di una città non è un vialetto più lungo.

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

App vs ecosistema: le differenze pratiche

Nota l'asimmetria nell'ultima riga. Scegliere "ecosistema" quando ti serviva solo un'app ti costa un po' di struttura sprecata. Scegliere "app" quando la tua visione era un ecosistema ti costa le fondamenta stesse: adattare a posteriori connessioni tra tipi di utenti su tabelle mai progettate per relazionarsi è il tipo di intervento che blocca i prodotti per mesi.

Perché devi decidere adesso, non dopo

Perché una complessità 10 volte maggiore è perfettamente gestibile quando la conosci in anticipo, e brutale quando la scopri a metà strada. Meglio saperlo ora che accorgersene dopo aver costruito le fondamenta sbagliate.

Decidere "ecosistema" presto sblocca anche la scelta strutturale più importante che rende possibili gli ecosistemi: progettare per più organizzazioni fin dal primo giorno, con ogni riga di dati che appartiene a una e una sola di esse. Quel pattern, il multi-tenancy, è quasi gratuito da inserire all'inizio e quasi impossibile da aggiungere dopo. È la prima conseguenza concreta della risposta alla domanda app contro ecosistema, ed è esattamente per questo che la domanda viene prima delle tabelle.

E per essere chiari, vale in entrambe le direzioni: se la risposta onesta è "app", costruisci un'app. Non gonfiare uno strumento mirato con un impianto da ecosistema perché suona più ambizioso. Il peccato non è la piccolezza; è il disallineamento.

L'esercizio: scrivi la visione, non le funzionalità

Prima della tua prossima tabella, prenditi venti minuti e scrivi la visione. Non l'elenco delle funzionalità: la visione. Tre domande fanno il lavoro:

Chi sono TUTTI gli utenti? Non solo quello ovvio. Chi altro tocca tutto questo: amministratori, partner, revisori, acquirenti, promotori? Come si collegano? Quali di loro devono vedere, condividere o agire sugli stessi record? Quali dati condividono? Quali informazioni scorrono tra loro invece di vivere nel silo di una sola persona?

Se le risposte sono "un solo tipo di utente, nessuna connessione, niente di condiviso", congratulazioni: stai costruendo un'app e il tuo database può restare splendidamente piccolo. Se le risposte coinvolgono più tipi di utenti che si scambiano dati, stai costruendo un ecosistema, e ogni tabella che progetti da questo momento dovrebbe saperlo.

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

Domande frequenti

Un ecosistema è meglio di un'app?

No: allineato è meglio che disallineato. Un'app mirata con un piccolo database adatto alla sua visione batte sempre un ecosistema a metà. Il punto non è puntare più in alto; è rendere il tuo database onesto su ciò che stai davvero costruendo.

Posso iniziare con un'app e crescere fino a un ecosistema?

Puoi, se le fondamenta lo permettono. Il compromesso che funziona: dimensiona le funzionalità come per un'app, ma fai la manciata di scelte fondamentali (multi-tenancy, organizzazioni come record di prima classe, riferimenti corretti) come se la visione dell'ecosistema potesse avverarsi. Le funzionalità sono facili da aggiungere dopo; le fondamenta no.

Di quante tabelle ha bisogno un ecosistema?

Non c'è un numero magico: 964 è ciò che ha richiesto un ecosistema reale di dieci prodotti, non un obiettivo. La risposta onesta è: quante ne richiede la visione, ed è esattamente per questo che scrivi prima la visione e lasci che il numero di tabelle ne discenda, non il contrario.

L'AI mi farà la domanda app contro ecosistema?

No, e questo è il pericolo. Chiedi all'AI "costruiscimi una piattaforma" e produrrà volentieri uno schema a forma di app, perché le app sono la media statistica di tutto ciò che ha visto. La visione vive nella tua testa. Esplicitala (tutti i tipi di utenti, le connessioni, i dati condivisi) e l'AI può progettare di conseguenza. Se la lasci implicita, ottieni la platea di un capanno sotto il tuo condominio.