Ho ucciso il mio primo SaaS prima di scrivere una riga di codice

Ho chiuso la prima stagione di Build in Public senza scrivere una riga di codice. E l’ho fatto apposta.

In questo episodio racconto perché ho deciso di buttare via la mia prima idea di SaaS – un tool sulle shipping policy per ecommerce – dopo aver parlato con persone vere, e non dopo 6 mesi chiuso a sviluppare.

Guarda il video su YouTube

Il contesto: un SaaS sulle shipping policy

Parto da un problema concreto che vivo da anni: ogni volta che apro un nuovo store su Shopify devo riscrivere da zero la pagina spedizioni/resi/policy.

Non è solo noiosa.

È anche rischiosa: normative che cambiano, mercati diversi, lingue diverse, copy che devi adattare ogni volta. E la tentazione di “copiare e incollare” da altri siti è sempre lì.

L’idea iniziale era semplice:

• un micro‑SaaS stile "Iubenda ma per le shipping policy",
• integrazione con le principali piattaforme ecommerce,
• generazione/aggiornamento delle pagine policy in modo guidato.

Sulla carta, sembrava sensata.

Il test: landing + gruppi Facebook + frizione

Invece di partire dal codice, ho fatto la cosa meno sexy ma più utile: una landing minimale e un giro serio di feedback.

1. Landing minimale

Ho montato una landing super grezza con un builder no‑code.

Obiettivo: spiegare il problema in poche righe, far vedere l’idea e raccogliere email solo da persone che si riconoscevano nel problema.

Niente design da Dribbble, solo:

• problema chiaro,
• promessa minima,
• form corto.

2. Domanda pubblica nei gruppi ecommerce

Poi ho portato la conversazione dove stanno le persone che potrebbero usarlo: gruppi Facebook di chi vende online.

Domanda secca:

Quanto sono davvero importanti per voi le pagine spedizioni/resi/policy? Avete mai visto casi in cui una pagina fatta male vi ha creato problemi, o una fatta bene vi ha salvato tempo, soldi e rogne?

Da lì è uscito di tutto.

I feedback (anche brutali) che hanno cambiato tutto

Alcune risposte mi hanno confermato che il problema esiste.

• “Più chiara è la policy, meno resi o problemi hai.”
• “Se vendi merce non coperta da diritto di reso, è fondamentale che sia chiarissima.”
• “Se la fai bene, spesso hai ragione e risolvi i casini più in fretta.”

Quindi sì, l’area è reale e tocca soldi, tempo e supporto.

Ma la maggioranza dei commenti andava in un’altra direzione:

• “Non stiamo parlando di marketing ma di termini di legge: ci pensa l’avvocato.”
• “Il cliente non le leggerà mai, serve a tutelare il merchant.”
• “Perché non paghi un avvocato che costa pure meno?”
• “Esiste già Iubenda, LexDoIt e altri mille tool. Che cazzo devi sviluppare?”

E qui si accende la spia rossa.

Il vero problema non era tecnico, era strategico

Quello che ho capito da questa frizione è semplice:

• la testa delle persone è settata su “avvocato + obbligo di legge”, non su “software che mi migliora la vita”;
• l’idea di “un altro tool AI per le policy” viene percepita come commodity, se non come fuffa;
• per spostare questa percezione dovrei fare una guerra di educazione al mercato che, onestamente, non ho voglia né tempo di combattere.

Non è il tipo di montagna su cui voglio arrampicarmi.

Perché ho scelto di buttare via l’idea

A questo punto avevo due strade:

1. ignorare il rumore, convincermi che “non hanno capito nulla” e chiudermi a scrivere codice per mesi;
2. prendere sul serio i segnali, accettare che l’idea non mi accende più e staccare la spina prima di investire troppo.

Ho scelto la seconda.

Non perché sia impossibile costruire qualcosa in questo spazio.

Ma perché, con le risorse e il tipo di creator/solofounder che sono, l’energia che dovrei spendere per educare il mercato non è allineata al rapporto rischio/ritorno che voglio.

E questo è esattamente il punto della mia serie: mostrare anche i progetti che MUOIONO in fretta, non solo quelli che ce la fanno.

La vittoria nascosta: tempo e focus salvati

Dire “ho fallito” a stagione 1 può sembrare deprimente.

In realtà:

• ho speso settimane, non anni;
• ho validato l’idea parlando con persone vere, non solo con il mio foglio Notion;
• ho confermato che posso buttare qualcosa senza sentirmi definito dal progetto.

Per un solofounder, saper staccare la spina è una skill.

Ogni idea che ammazzi in fretta ti restituisce tempo, focus e lucidità per la prossima.

Cosa mi porto dietro per la prossima stagione

Da questa mini‑stagione mi porto tre criteri chiari per le prossime idee:

1. Mercato che vede subito il valore del software, non solo della consulenza.
2. Problema abbastanza “doloroso” da far sì che le persone cerchino attivamente soluzioni, non solo commentino post.
3. Spazio dove mi vedo volentieri per mesi, non solo dove potrei fare “un progettino interessante”.

La prossima stagione di Build in Public parte da qui.

Non da un “genio in garage” che ha sempre ragione.

Ma da uno che preferisce fallire in pubblico, in piccolo, per aumentare le probabilità di centrare qualcosa di grande tra qualche tentativo.

Se vuoi vedere il racconto completo, con il dietro le quinte del video e tutta la parte emotiva, qui c’è l’episodio su YouTube:

▶ Guarda il video: Ho ucciso il mio primo SaaS prima di scrivere una riga di codice