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

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

Non è solo noiosa.

È rischiosa: normative che cambiano, mercati diversi, lingue diverse, copy da adattare ogni volta. E la tentazione di copiare e incollare da altri siti è sempre lì, a un click di distanza.

L'idea era semplice:

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

Sulla carta, sensata. Come tutte le idee sulla carta.

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

1. Landing minimale

Landing super grezza, builder no-code.

Obiettivo: spiegare il problema in poche righe, far vedere l'idea, raccogliere email solo da chi si riconosceva 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 quelli 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.

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. 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 lì si accende la spia rossa.

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. Nella migliore delle ipotesi. Nella peggiore, come fuffa;
• per spostare questa percezione dovrei fare una guerra di educazione al mercato che, onestamente, non ho voglia né tempo di combattere.

Non è la montagna su cui voglio arrampicarmi. Punto.

A quel punto avevo due strade:

1. ignorare il rumore, convincermi che "non hanno capito niente" 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 investirci troppo.

Ho scelto la seconda.

Non perché sia impossibile costruire qualcosa in questo spazio.

Ma perché, con le risorse che ho e il tipo di solofounder che sono, l'energia che dovrei spendere per educare il mercato non sta in piedi rispetto al rischio/ritorno che voglio.

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

Dire "ho fallito" alla stagione 1 sembra deprimente.

In realtà:

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

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

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

Da questa mini-stagione mi porto tre filtri chiari per le prossime idee:

1. Mercato che vede subito il valore del software, non solo quello della consulenza.
2. Problema abbastanza doloroso da far cercare attivamente soluzioni, non solo da far commentare sotto un 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 grosso tra qualche tentativo.

---

Se vuoi il racconto completo, con il dietro le quinte e tutta la parte emotiva, ecco l'episodio su YouTube:

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