u/Holdfast-app

Ho sviluppato Holdfast, uno strumento per il recupero dei pagamenti non andati a buon fine per i SaaS di Stripe. Immaginate tentativi di pagamento automatici + email di sollecito intelligenti, a un costo fisso di 29 dollari al mese invece del 10-20% che si prendono i concorrenti.

Ho lanciato una landing page, ho iniziato a pubblicare in alcune community e ho ottenuto un po' di traffico. Zero iscrizioni.

Ho chiesto un feedback sul design qui e qualcuno ha detto che sembrava "in stile haiku". Non sapevo se ridere o piangere, quindi l'ho preso come un brief.

**Cosa c'era di sbagliato nell'originale:**

Il titolo era "Holdfast - Recupero dei pagamenti per SaaS e creatori". Pura descrizione della funzionalità. Nessun problema di inquadramento, nessuna urgenza, nessun motivo per interessarsi.

Il modulo di iscrizione aveva 4 campi: nome, email, intervallo MRR, processore di pagamento. Per una *lista d'attesa*. In pratica, stavo chiedendo una mini chiamata di vendita prima ancora di salutare.

C'erano due sezioni — "Come funziona" e "Caratteristiche" — che descrivevano esattamente le stesse cose con parole diverse. Nessuno se n'è accorto, me compreso.

La pagina era bianca e minimalista, al punto da sembrare incompiuta. Un commento su Reddit l'ha definita "in stile haiku". Un altro ha detto "troppo semplice".

**Cosa ho cambiato:**

1. Ho riscritto il titolo per inquadrarlo come una perdita: *"I pagamenti non andati a buon fine stanno silenziosamente prosciugando il tuo MRR."* Il sottotitolo spiega cosa fa Holdfast. Prima era il contrario.

2. Ho aggiunto un calcolatore interattivo. Impostando il tuo MRR e il tasso di mancato pagamento, il calcolatore mostra l'importo esatto in dollari che viene perso mensilmente e annualmente, e quanto Holdfast recupererebbe. Ho reso il problema personale e quantificabile. 3. Ho ridotto il modulo a solo nome e email. Ovvio col senno di poi.

3. Ho eliminato completamente una delle due sezioni ridondanti.

4. Ho adottato la modalità scura completa con i colori del brand. L'originale sembrava un segnaposto.

**Cosa non ho fatto:**

Mi sono rifiutato di aggiungere false testimonianze o numeri di clienti inventati. Molti consigli sulle landing page dicono "aggiungi prove sociali!", ma inventarle mi sembrava peggio che non averne affatto. Invece ho aggiunto una barra delle integrazioni (Stripe, Resend, Slack): dati veritieri e che segnalano credibilità tecnica senza mentire.

**A che punto è:**

Ancora in beta privata, sto ancora raccogliendo iscrizioni alla lista d'attesa. La pagina è online all'indirizzo [tryholdfast.app](http://tryholdfast.app) se volete vedere il risultato finale. Sono felice di sapere se c'è qualcos'altro che non va: l'ultima volta il feedback è stato brutale ma utile.

Ho approfondito la questione per Holdfast ed è incredibile quanti fondatori (me compreso) considerino il "pagamento non riuscito" come un'unica categoria.
Stripe restituisce un codice di rifiuto per ogni transazione non andata a buon fine. Due categorie principali:
**Rifiuti temporanei** — in questi casi è consigliabile riprovare
fondi_insufficienti

riprova_più_tardi

errore_di_elaborazione

In questi casi la carta è valida, ma qualcosa di temporaneo l'ha bloccata. Il tempismo del tentativo di pagamento è fondamentale: riprovare subito dopo un errore di fondi_insufficienti è inutile, probabilmente il saldo non è cambiato negli ultimi 10 minuti. Aspettare un giorno o due, idealmente intorno al periodo in cui il cliente potrebbe ricevere lo stipendio, funziona davvero.

**Rifiuti definitivi** — permanenti, riprovare è uno spreco
carta rubata

carta smarrita

carta scaduta

non accettata

Nessun numero di tentativi risolve questi problemi. Se riprovi un rifiuto per carta rubata con la stessa frequenza di un rifiuto per fondi insufficienti, stai sprecando tentativi (alcuni processori limitano la frequenza o segnalano i tentativi eccessivi) su una carta che non andrà mai a buon fine.
La soluzione non è complicata: leggi il codice di rifiuto dal pagamento non riuscito e diluisci la logica dei tentativi in ​​base a esso. I rifiuti definitivi dovrebbero passare direttamente all'email "Aggiorna il tuo metodo di pagamento", non rimanere in coda per i tentativi.

I tentativi di pagamento intelligenti di Stripe gestiscono già in parte questo aspetto, ma se utilizzate una logica di sollecito personalizzata (molti creano email personalizzate anche con i tentativi di pagamento intelligenti che gestiscono il retry), probabilmente vorrete la stessa ramificazione nella vostra sequenza di email: "la tua carta è stata rifiutata" ha un significato molto diverso a seconda che si tratti di una carta scaduta o di una carta non valida.
Qualcun altro gestisce i codici di rifiuto in modo diverso nel proprio flusso di sollecito, o riprova tutto con la stessa pianificazione?

been staring at my churn number for weeks now and something bugs me.

some of it is people who genuinely don’t want the product anymore. fine, that’s normal, that’s business.

but some of it is just… expired cards. banks blocking transactions. retries failing silently in the background. people who never actually decided to leave, they just stopped getting charged and nobody noticed until the mrr graph moved.

do you guys separate the two in your dashboards or does it all just blend into one churn number? feels like an easy thing to overlook until it’s not.

sto lavorando su un tool per il recovery dei pagamenti falliti su stripe (dunning automatico + reminder ai clienti). una cosa che continuo a sentire da altri founder è che i failed payments sono silenziosi — stripe smette di ritentare dopo un po’, il cliente non cancella attivamente, semplicemente il pagamento si perde e nessuno se ne accorge finché non guardi i numeri.

sto cercando di capire quanto questo sia un problema reale per chi è a $2-30k mrr. lo controllate regolarmente o è una cosa che scoprite per caso?

sto notando un pattern in me e volevo capire se è comune. ogni volta che lancio qualcosa, le prime due settimane sono ansia pura e voglia di controllare le metriche ogni ora. zero segnali e la mente inizia a chiedersi se il problema è il prodotto, il messaggio, o solo il tempo.

il problema è che non ho un criterio chiaro per distinguere “non ha ancora avuto tempo” da “non funzionerà mai”. due settimane sembrano poche per giudicare, ma sembrano anche troppe quando non si muove nulla.

per chi ha lanciato più di un progetto: che criterio usate per decidere se continuare a spingere o mollare? un numero di settimane, di utenti, una sensazione, o quando finiscono soldi/motivazione?

Ciao a tutti,

Sono Andrea e sto sviluppando Holdfast. Voglio condividere la versione onesta della situazione attuale, senza metriche gonfiate o esagerazioni.

Il problema che sto risolvendo

I pagamenti non andati a buon fine sono uno di quei problemi che non vengono mai considerati "abbastanza urgenti" da risolvere in modo adeguato. La maggior parte dei fondatori di SaaS con cui ho parlato sa che stanno causando perdite, ma non sa quanto, e implementare un sistema di sollecito efficace sembra una distrazione.

I calcoli sono impietosi: con un MRR di 50.000 dollari e un tasso di fallimento del 3%, si perdono 18.000 dollari all'anno. Un sistema di retry e sollecito adeguato recupera circa il 62% di questa somma. La maggior parte dei fondatori non ha configurato nulla di tutto ciò.

Cosa sto costruendo

Holdfast si connette al tuo sistema di elaborazione dei pagamenti, ritenta automaticamente i pagamenti non andati a buon fine secondo una pianificazione intelligente e invia sequenze di email di sollecito programmate per massimizzare il recupero. L'obiettivo è zero configurazione: lo connetti una volta e funziona in background.

La visione è indipendente dal sistema di elaborazione dei pagamenti: si inizia con Stripe, poi si passa a Paddle, Lemon Squeezy e altri.

Dove mi trovo ora

Sono in una fase iniziale. Ho lanciato la lista d'attesa la settimana scorsa su tryholdfast.app. Non c'è ancora un prodotto, solo una landing page con un calcolatore e un modulo. Sono in fase di validazione: voglio parlare con più di 30 fondatori di aziende SaaS prima di costruire qualcosa di serio.

Nessun ricavo. Nessun utente. Solo un'ipotesi e tante conversazioni da affrontare.

Perché pubblico questo post

Onestamente, per trovare persone che si occupano di questo problema. Se avete mai pensato ai pagamenti non andati a buon fine, che li abbiate risolti o meno, mi piacerebbe sapere come li gestite.

E se siete curiosi di sapere come è andata a finire, continuerò a pubblicare aggiornamenti qui.

👉 tryholdfast.app

Most SaaS tools treat failed payments as a technical issue: retry the card, maybe send one email, move on.

But when I dug into the data, the recovery rate difference between "retry only" and "retry + email sequence" is massive. Stripe's Smart Retries alone recover ~21% of failed charges. Add a well-timed dunning sequence and you get to 60%+.

The delta isn't technical — it's about reaching the customer at the right moment with the right message.

Most people don't cancel their subscription because they want to leave. They forget to update their card. They had a temporary hold. Their bank flagged something weird. A single email sent 24 hours after the failure — not 5 days later, not a generic "payment failed" alert — recovers a huge chunk of those.

The companies that do this well treat the dunning email like a product touchpoint, not a billing notification.

Curious how others here handle this. Are you using Stripe's built-in retries? A tool? Custom sequences? What's worked?

(I'm building Holdfast to automate this — early access at tryholdfast.app if this is a pain you deal with)