Disegniamo e sviluppiamo prodotti fintech
Da un'idea fintech al prodotto in produzione, con utenti veri e ricavi misurabili. Disegniamo e sviluppiamo tutto: sito di marketing, app, back-office, integrazione di pagamenti e identità.
Quello che vediamo più spesso
Coordinare cinque mestieri diventa il tuo lavoro
Un fintech è un sito di marketing, un'app consumer, un back-office, un'integrazione di pagamenti, una verifica di identità, un'infrastruttura dati. Per ognuno serve un mestiere diverso, e il founder finisce a fare il project manager invece di costruire il prodotto.
Tra MVP e prodotto vero c'è un cantiere
L'MVP funziona per i primi utenti. Per arrivare al prodotto vero serve gestire dieci volte quei numeri, i casi limite dell'onboarding, gli stati di errore della verifica di identità, le riconciliazioni di fine mese. Quel cantiere lo scopri quando lo devi attraversare.
Fare le integrazioni una per volta porta via mesi
Stripe o Adyen per i pagamenti. Onfido o Veriff per l'identità. Mastercard o Visa se emetti carte. Mambu o Thought Machine se serve un core banking. Ognuno è un fornitore con la sua API, il suo flusso di webhook, la sua documentazione. Cucirli in modo che dall'esterno sembri un prodotto solo richiede trimestri di lavoro.
Tra il prototipo Figma e il prodotto in mano agli utenti c'è uno scarto
Figma è uno screenshot fermo. Il prodotto in mano è dinamico, con caricamenti, stati di errore, tastiera che apre e nasconde i bottoni, campi che reagiscono a velocità diverse. Quello scarto è dove un prodotto che gestisce denaro perde o guadagna la fiducia di chi lo usa.
kiBank, una neobank disegnata e sviluppata interamente da noi
Abbiamo disegnato e sviluppato kiBank: sito di marketing, app, design system, infrastruttura. Una schermata l'abbiamo tenuta solo se toglie un attrito a chi la usa.
Come affrontiamo il fintech
Quando lavoriamo a un prodotto fintech, partiamo da un'idea e arriviamo a un prodotto vero, con utenti veri e ricavi misurabili: una transazione, una sottoscrizione, una vendita, un cliente che cambia stato. Per arrivarci serve disegnare l'interfaccia, scrivere la logica del back-office, integrare il provider dei pagamenti e la verifica dell'identità. Lo facciamo come un solo prodotto, disegnando l'interfaccia mentre scriviamo l'infrastruttura.
Mandiamo in produzione il design che abbiamo approvato. Cuciamo l'integrazione di pagamenti sull'esperienza già in fase di disegno. Dopo il rilascio aggiungiamo le feature nuove nello stesso prodotto, senza aprire un cantiere parallelo.
kiBank è la versione in produzione di questo modo di lavorare. Abbiamo disegnato il blocco della carta nello stesso passaggio in cui abbiamo scritto le policy sulla riga del database. Per chi la usa, kiBank è un'app che funziona e basta. Il resto del lavoro è rimasto dentro al codice.
Cosa portiamo in produzione, in questo settore
L'app consumer, completa
Onboarding con verifica di identità, schermate di saldo, transazioni, invio e ricezione di denaro, gestione delle carte, supporto. Una sola libreria di componenti che funziona su iOS, Android e web con la stessa fedeltà.
Il back-office che il team usa otto ore al giorno
Una dashboard con permessi per ruolo, vista delle transazioni, gestione delle dispute, esportazioni regolatorie, registro firmato delle operazioni. La pensiamo per chi ci lavora ogni giorno, non per la demo che vedrà il fondo nella due diligence.
L'integrazione di pagamenti e identità dentro al codice del prodotto
Stripe o Adyen per i pagamenti, Onfido o Veriff per l'identità, screening automatico sulle liste internazionali. L'integrazione sta dentro al codice del prodotto, con lo stesso schema di stato che il team di supporto consulta, non come microservizio a parte dietro un'interfaccia REST.
Un design system già provato sul banking
Componenti che abbiamo provato su un prodotto bancario in produzione: pulsanti per le azioni che muovono denaro, schermate di conferma, stati di errore tarati per la fiducia su numeri sensibili, micro-interazioni che funzionano con una mano sul telefono. Non lo cominciamo da zero a ogni progetto.
Lo stack che scegliamo per il fintech
Scegliamo ogni livello dello stack per due momenti diversi. Il primo è il giorno del rilascio: vogliamo un'app che carichi veloce, un pagamento che parta al primo colpo, un back-office che faccia quello che serve al team. Il secondo è il giorno in cui un cliente regolato comincia a chiedere come funziona.
Mettiamo il sito di marketing e la parte web dell'app nello stesso repository Next.js. Teniamo i dati dei clienti separati direttamente sulla riga della base dati, non nel codice dell'applicazione, e così l'ufficio acquisti del cliente enterprise riceve una risposta che sta in poche righe leggibili anche da chi non scrive codice. I dati della carta non li tocchiamo nei server: Stripe Elements, o Adyen drop-in, li intercetta dal browser e restituisce un token, e per l'attestazione PCI annuale basta la tariffa più leggera.
Il registro contabile è event-sourced: ogni saldo si ricostruisce dalla traccia degli eventi senza toccare nessuna stored procedure. Scriviamo tutto il codice in TypeScript, dalle query alla vista. Chi apre il codice dopo l'autore originale lo legge senza una visita guidata.
Domande che fanno i founder
Avete una licenza vostra o vi appoggiate a un partner?
Una licenza nostra no. Per emissione di carte, pagamenti o raccolta depositi ci appoggiamo a un provider che la licenza ce l'ha, e cuciamo noi l'integrazione. La controparte legale resta l'ente licenziato. Noi rispondiamo del prodotto e del codice di integrazione.
Vi collegate al nostro core banking?
Sì. Abbiamo già integrato Mambu, Thought Machine, e un paio di sistemi di open banking europei. Se il core espone un'API sensata e un flusso di webhook, ci colleghiamo. Se non li espone, gli costruiamo intorno un wrapper.
Come gestite il primo pagamento di un cliente nuovo?
Manteniamo la sessione attiva mentre il cliente passa per la pagina di conferma della propria banca. Per il flusso da mobile c'è un percorso alternativo dentro l'app. La carta non si rimette mai a mano.
Si può fare un audit finanziario sul vostro registro?
Sì. A partita doppia, in sola scrittura, event-sourced. Il revisore riceve accesso in sola lettura e ricostruisce i saldi dal replay degli eventi. Abbiamo già accompagnato revisori dentro al sistema, e sono usciti senza domande in sospeso.
Vi occupate anche delle pratiche regolatorie?
No. Lavoriamo accanto ai legali e ai consulenti di compliance che porti tu. Se serve, suggeriamo partner con cui abbiamo già rilasciato progetti, ma le pratiche regolatorie non le firmiamo.
Raccontaci il prodotto
Una chiamata per inquadrare il lavoro, un numero concreto nella prima risposta, e niente pitch deck con case study tutti uguali.