Design e sviluppo per founder SaaS
Checkout integrato con Stripe, auth multi-tenant, dashboard che fanno emergere il valore prima del churn. Il prodotto subscription intero, non solo una landing.
I problemi che sentiamo più spesso
Stripe, Customer.io, Intercom e un Google Sheet per le proroghe trial
Cinque strumenti che non si parlano, nessuno sa quante settimane di runway brucia ogni mese.
Il founder che corregge a mano gli eventi di onboarding alle 23
Nessun tracciamento attivazione, nessun funnel, nessun modo di capire quale step uccide la conversione.
Dashboard che dicono cosa ma mai perché
I clienti escono e il team lo scopre dalla mail di cancellazione. Il valore non emerge dove serve.
Una pricing page che parla agli ingegneri, non a chi compra
Piani copiati da un competitor, tabella comparativa che nessuno legge, nessun metering legato al billing.
Moko · otto aree, un design system
Uno spazio di lavoro per l'assistenza clienti, progettato e costruito da capo. Inbox, dettaglio ticket, clienti, knowledge base, report, macro, impostazioni, portale cliente. Otto aree di produzione, un design system, un solo team.
Dentro la build di Moko
Moko sostituisce gli strumenti su cui un team di assistenza clienti passa la giornata: inbox, dettaglio ticket, clienti, knowledge base, report, macro, impostazioni e portale cliente. Il brief era costruire ogni area con lo stesso livello di rifinitura, non una pagina principale rifinita seguita da sette aree lasciate a metà. È la forma di lavoro che rompe quasi tutti gli strumenti di assistenza dopo il lancio: l'inbox si prende tutta l'attenzione, i report non vedono mai la stessa cura, il portale cliente è un'aggiunta dell'ultimo minuto. Abbiamo trattato tutte e otto le aree alla pari, e il design system ha assorbito il costo di farlo.
Il design system era il progetto
Otto aree che condividono la stessa rifinitura significa che è il design system a portare il progetto, non il contrario. Abbiamo iniziato costruendo i componenti che inbox, profilo cliente e report avrebbero condiviso, ovvero bottoni, badge, status pill, modali, dropdown, righe di tabella e grafici, e poi abbiamo assemblato le superfici sopra quella base. Nessuna schermata ha avuto un trattamento speciale, nessuna superficie ha negoziato una variante one-off, e il team che ha finito per usare il sistema su scala era abbastanza piccolo da rendere la coerenza una feature, non un peso di processo.
L'inbox keyboard-first
L'inbox è la pagina più importante. Un agente ci si muove dentro continuamente. Il composer alterna tra risposta pubblica e nota interna con un cambio di colore che rende chiara al volo la modalità prima di inviare. I cambi di stato sono ottimistici con rollback, quindi l'interfaccia non si blocca mai aspettando il server. Tag e priorità si modificano inline, mai in un dialog. Una card di AI summary compare sopra i thread con tre o più messaggi e mostra il sentiment, il contesto del piano e un next step suggerito. Un refresh con un click rigenera il suggerimento quando l'agente vuole un altro taglio.
L'inbox ha cinque scorciatoie da tastiera: scorrere la lista delle conversazioni, muoversi tra gli stati, aprire l'AI summary, inserire una macro, inviare la risposta. L'overlay di aiuto le insegna nello stesso punto in cui si usano. Chi le impara non torna più al mouse.
Un profilo cliente che non mente
Ogni cliente arriva con la sua storia. Il profilo 360 affianca una striscia di statistiche alla lista completa dei ticket e un editor di custom field che aggiunge, modifica e rimuove inline con feedback immediato. Lo stesso schema alimenta il drawer dell'inbox, così un agente che apre una conversazione vede già piano, location, CSAT lifetime e ultimi ticket del cliente senza uscire dal thread. Niente tab da cambiare, niente sidebar da aspettare. Una sola forma di dato, usata in due posti.
Una knowledge base che è due prodotti in uno
Il lato admin è un CMS per contenuti di assistenza con categorie, bozze e stato pubblicato. Il lato pubblico, servito su /help, è un layout in stile marketing con hero search, card di categoria e indice per articolo. Entrambi i lati leggono dagli stessi dati, così un agente che aggiorna un articolo non deve fermarsi a pensare a quale superficie lo vedrà il lettore. Lo stesso articolo che si ancora a una risposta di assistenza è l'articolo che il cliente trova in self-service tramite la ricerca.
Le macro come sistema di templating
Le macro non sono un menu di risposte rapide, sono un sistema di templating leggero. Le variabili si risolvono dal ticket e dal cliente in vivo nel momento in cui l'agente inserisce la macro, così lo stesso template sembra scritto per la persona dall'altra parte. La combinazione di macro, card di AI summary e modifiche inline è ciò che trasforma l'inbox da lista a spazio di lavoro.
Light e dark dal primo commit
Ogni schermata nasce in light e in dark dal primo commit. L'intero prodotto è token-driven: nessun colore hardcoded, nessun peso del font hardcoded, nessun inline style da nessuna parte del codice. Il design system porta con sé la palette, la scala tipografica, i radius e i livelli di elevation in entrambi i temi. Grafici e badge leggono dagli stessi token dei bottoni, così un cambio di tema non racconta mai bugie su cosa è interattivo. Nella superficie dei report vivono quattro tipi di grafico, e ognuno è agganciato ai token del design system, così un cambio di colore nel sistema si propaga nel prodotto con un singolo commit.
Perché questa forma conta per un founder SaaS
Un SaaS completo non è il sito di marketing più un MVP. È l'inbox in cui ci lavora il team di assistenza, il registro contabile che legge il team finance, i report che il founder controlla prima di un board meeting, e il portale in cui il cliente entra per gestire il proprio piano. Moko è la forma di lavoro che chiude tutto questo cerchio con un solo design system, non otto team che cuciono otto superfici incoerenti. Il risultato è un prodotto che non chiede di essere riscritto quando il team cresce o il brand si evolve.
Quello che il lavoro ha consegnato
Otto aree sotto un solo design system. Cinque scorciatoie da tastiera nell'inbox. Quattro tipi di grafico legati ai token del design. Zero valori hardcoded nel codice.
Cosa consegniamo in questo verticale
Auth multi-tenant con Supabase RLS
Row-level security che regge un audit, isolamento tra tenant garantito a livello di riga.
Billing Stripe con prorating
Checkout, Subscriptions, Customer Portal, router eventi webhook.
Onboarding con tracciamento attivazione
Eventi di funnel legati alle azioni che davvero predicono la retention.
Dashboard admin
Cockpit interno per supporto, rimborsi, migrazioni piano.
Router eventi webhook
Handler idempotenti, coda retry, logging dead-letter.
Permessi role-based
Owner, admin, member, billing. Validati lato server, non solo in UI.
Metering uso
Lega il consumo ai limiti di piano e alle fatturazioni a valle.
Prevenzione abuso trial
Heuristic su email e fingerprint, niente reset-da-incognito.
API surface
Versionata, documentata, rate-limited. I clienti smettono di chiedere export CSV via email.
Feature flag
Spedisci in un branch, rollout per tenant, kill switch in oncall.
Audit log
Ogni azione privilegiata attribuibile, esportabile, interrogabile.
Export ed eliminazione dati GDPR
Self-service, un solo bottone, zero ticket all'engineering.
Uno stack pensato per il ciclo del SaaS
Ogni livello qui esiste per ripagarsi due volte: la prima quando stai mettendo online la prima versione del prodotto, la seconda quando inizi a crescere, ad assumere o ad affrontare le domande dure dell'ufficio acquisti di un cliente enterprise. Scegliamo lo stack che regge proprio in quel secondo momento.
Il sito di marketing, la dashboard interna all'app e il pannello di amministrazione stanno tutti dentro lo stesso codice, costruito su Next.js App Router, quindi la pagina dei prezzi viene indicizzata da Google come fosse una pagina statica, la dashboard si carica rapida al primo clic dell'utente, e gli sviluppatori non passano mezza giornata a litigare su quale framework debba ospitare il flusso di registrazione. Un solo repository, un solo rilascio, e il team marketing e il team prodotto lavorano nello stesso posto.
I dati dei clienti sono isolati a livello di database, non nel codice applicativo, e questo è il punto: il primo contratto importante che andrai a chiudere passerà da una revisione di sicurezza, e quella revisione farà sempre la stessa domanda, cioè come garantisci che il cliente A non possa vedere i dati del cliente B. Con Supabase Postgres e la sicurezza a livello di riga la risposta è dimostrabile in una sola schermata di codice, e la puoi mettere per iscritto. Lo stesso database gestisce anche gli account utente, il caricamento dei file e gli aggiornamenti in tempo reale, così non ti ritrovi a tenere insieme tre servizi diversi che non concordano nemmeno su chi sia l'utente.
Abbonamenti, cambi di piano in salita e in discesa, tentativi di riscossione, fatture, rimborsi, tutto costruito su Stripe Subscriptions e Customer Portal, in modo che il livello di fatturazione cresca insieme al prodotto e non chieda una riscrittura quando inizi a scalare. Colleghiamo le parti in movimento perché una caduta di Stripe non lasci il registro contabile fuori sincronia. I clienti gestiscono il proprio piano in autonomia, cancellano, riattivano, scaricano le ricevute, e il supporto smette di occuparsi anche della fatturazione.
Un'infrastruttura che non sfugge di mano nei costi mentre il prodotto cresce: Upstash Redis vicino all'utente si occupa di limitare le chiamate e di proteggere dagli abusi senza che tu debba gestire un server, mentre Cloudflare R2 conserva i file dei clienti, così un utente che scarica lo stesso file a ripetizione non si trasforma in una sorpresa a quattro cifre sulla fattura. Costi prevedibili, niente sorprese.
Ogni chiamata all'API, ogni interrogazione al database e ogni elemento di interfaccia è tipizzato con TypeScript: è un beneficio poco appariscente ma portante, perché quando qualcuno lascia il team, quando sostituisci uno sviluppatore, quando rinomini una funzionalità, il prodotto non si rompe in silenzio. La persona che apre il codice subito dopo riesce a muoversi al suo interno senza bisogno di una visita guidata.
Domande che fanno i founder
Ho già un MVP su Bubble. Si può ripartire da lì?
Sì, lo migriamo. La logica costruita dentro Bubble la riscriviamo in codice vero, i dati passano su Postgres, e il prodotto nuovo va online come un'applicazione vera e non come un prototipo no-code con un soffitto sopra.
Mi serve solo la parte di fatturazione, la fate?
Sì, e con un perimetro chiaro: Stripe Checkout, Stripe Subscriptions e Customer Portal come modulo a sé, con i webhook collegati e una vista di amministrazione per il tuo team. Il perimetro e il prezzo dipendono da quanto è articolato il modello di pricing.
Come evitate l'abuso dei trial gratuiti?
Con tre controlli sovrapposti: euristica sul dominio dell'email, impronta del browser al momento della registrazione, e un tetto per indirizzo IP e per dispositivo sui tentativi consecutivi. Lo trattiamo come uno strato di sicurezza, non come un trucco di marketing.
Il tracciamento dell'attivazione lo configurate voi o lo porto io?
Sia l'una che l'altra. Abbiamo un default di cui ci fidiamo (PostHog più un piccolo wrapper lato server), e se hai già uno strumento che paghi ci colleghiamo a quello.
Qual è il perimetro minimo che spedite per portare i primi clienti paganti?
Autenticazione, fatturazione e un singolo flusso centrale fatto bene. Le dashboard, le viste di amministrazione e le integrazioni arrivano dopo, quando i clienti paganti ti dicono quale serve per prima. Tagliamo il superfluo prima di costruire, non dopo.
Restate anche dopo il lancio?
Due strade possibili: passaggio pulito con tutta la documentazione e il design system in mano al tuo team, oppure restiamo come partner continuativo. Non spariamo via dopo il lancio.
E se voglio tenere l'agenzia che mi segue per il marketing?
Nessun problema. Noi ci occupiamo della parte di prodotto, loro restano sul sito di brand, e ci coordiniamo sul CMS condiviso e sull'analitica così nessuno dei due lavora al buio.
Quanto costa un progetto completo?
Le fasce di prezzo le trovi sul modulo di contatto. Dopo una chiamata per inquadrare il progetto rispondiamo con un numero concreto, non con una brochure.
Raccontaci il tuo SaaS
Una chiamata per inquadrare il progetto, un numero concreto nella prima risposta, zero teatro da agenzia.