C’è un momento che ogni ingegnere conosce. Ottieni l’accesso a un nuovo repository, apri i primi file e capisci subito che la conversazione sarà più lunga di quanto il cliente si aspettasse.
Nel fintech quel momento capita più spesso di quanto dovrebbe. E dopo averlo vissuto abbastanza volte, gli schemi diventano molto familiari.
"Dobbiamo solo aggiungere una funzionalità"
Quasi sempre inizia così.
Un’azienda fintech arriva con una richiesta precisa. Aggiungere un nuovo metodo di pagamento. Integrare un provider KYC. Sviluppare un modulo di monitoraggio delle transazioni. Il perimetro sembra chiaro, i tempi ragionevoli e il budget sembra sufficiente.
Poi apri il codice.
Quella che sembrava la richiesta di una singola funzionalità poggia su un’architettura costruita da cinque persone diverse in tre anni, che non si sono mai parlate. La logica dei pagamenti si trova in quattro punti diversi. Il modulo di autenticazione è stato scritto da un freelance ormai irraggiungibile. Nel progetto convivono due modi diversi di connettersi al database, usati senza coerenza. E la "rapida integrazione KYC" di diciotto mesi fa sta in piedi grazie a valori hardcoded e a un commento che dice "sistemare dopo".
Il problema non è la funzionalità. Sono le fondamenta.
Come si arriva a un codice del genere
Non è negligenza. È economia, o almeno sembra tale al momento.
I prodotti fintech vengono sviluppati in fretta perché devono esserlo. Le aziende early-stage assumono chi è disponibile: un freelance per il frontend, un’agenzia per il backend, un consulente specializzato per l’integrazione dei pagamenti. Ognuno consegna qualcosa che funziona da solo. Nessuno è responsabile di come tutto si incastra.
Poi l’azienda cresce. Arrivano nuovi requisiti. Un nuovo sviluppatore entra nel team e aggiunge i suoi schemi sopra quelli esistenti. Un requisito di compliance impone una correzione rapida, attaccata sopra invece che integrata correttamente. Si aggiunge un nuovo provider di pagamento senza rifattorizzare la logica esistente, perché non c’è tempo.
Sei mesi dopo, il codice riflette la storia delle assunzioni dell’azienda più di qualsiasi visione tecnica coerente. E il costo di ogni nuova funzionalità raddoppia silenziosamente, perché metà del lavoro consiste nel capire cosa c’è già.
Cosa troviamo davvero
Dopo aver messo mano a parecchi progetti fintech, l’elenco dei problemi ricorrenti diventa prevedibile.
Logica dei pagamenti sparsa ovunque. Creazione delle transazioni, validazione, gestione degli errori, logica di retry: divise tra controller, servizi, job in background e qualche file helper che nessuno sa spiegare. Una modifica in un punto rompe qualcosa di inaspettato altrove.
Autenticazione costruita a strati. Il flusso di login originale c’è ancora. Sopra, qualcuno ha aggiunto OAuth. Sopra ancora, sei mesi fa un freelance ha aggiunto la 2FA in un modo che aggira parte della gestione originale delle sessioni. Nessuno è sicuro che i tre livelli si comportino in modo coerente.
Un’integrazione KYC che funziona finché non smette di funzionare. Il caso ideale (l’utente invia un documento valido, il sistema lo accetta) funziona bene. Tutto il resto (documenti scaduti, verifiche fallite, code di revisione manuale, flussi di retry, webhook di stato) manca, non funziona o viene gestito in modo diverso a seconda dell’ultimo sviluppatore che ci ha messo mano.
Nessun test, o test che non testano nulla. Una suite di test c’è. È tutta verde. Testa esattamente gli input usati dallo sviluppatore originale per costruire la funzionalità, non i casi limite che emergono in produzione. La prima volta che un utente reale fa qualcosa di inatteso, il sistema lo scopre in produzione.
Documentazione che descrive il sistema come era stato pianificato, non come esiste. Il diagramma di architettura del primo sprint è ancora nella wiki. Non ha quasi nessun rapporto con ciò che è stato effettivamente costruito.
Il costo reale della responsabilità frammentata
L’istinto di dividere il lavoro tra più team, agenzie e freelance ha senso nel breve periodo. Sembra più veloce ed economico. Pagate singoli deliverable, non un team intero.
Ciò che si perde è la coerenza.
Quando cinque persone costruiscono indipendentemente cinque parti di un sistema, non ottenete un sistema. Ottenete cinque sistemi che per caso condividono un database. Integrarli correttamente, in modo che si comportino in modo coerente, gestiscano gli errori con eleganza e si possano estendere senza effetti collaterali, è un lavoro che nessuno ha messo a budget perché nessuno pensava fosse necessario.
E nel fintech in particolare, l’incoerenza ha conseguenze. Un modulo di pagamento che gestisce gli errori in modo incoerente perde denaro. Un livello di autenticazione con delle falle crea esposizione alla sicurezza. Un flusso KYC che si rompe nei casi limite crea rischi di compliance. Non sono problemi astratti. Sono esattamente i problemi che emergono in produzione nel momento peggiore.
Un unico team responsabile dell’intero sistema (architettura, implementazione e integrazione) costa di più a sprint rispetto a un insieme di freelance. Costa molto meno che sistemare ciò che i freelance hanno costruito separatamente.
Come si presenta un buon codice
Un codice fintech ben costruito è noioso da guardare. Tutto è dove ci si aspetta che sia. La logica dei pagamenti sta in un unico punto. L’autenticazione è un unico sistema coerente. L’integrazione KYC gestisce successi e fallimenti con la stessa cura. C’è un test per il caso limite, non solo per il caso ideale.
Quando arriva un nuovo requisito, potete aggiungerlo senza passare prima due settimane a capire cosa c’è già. Quando qualcosa si rompe in produzione, lo trovate in pochi minuti invece che in ore.
Non è uno standard più alto di quello a cui aspira la maggior parte dei team. È semplicemente ciò che succede quando un unico team è responsabile di tutto fin dall’inizio, e continua a rispondere di come il sistema regge nel tempo.
L’unica domanda che vale la pena porsi
Prima di definire il perimetro della prossima funzionalità, vale la pena porsi onestamente una domanda: il team che la svilupperà capisce davvero il sistema su cui la sta costruendo?
Se la risposta è "più o meno" o "lo scopriremo", la funzionalità costerà più del preventivo, richiederà più tempo del previsto e lascerà il codice un po’ più difficile da gestire di prima.
Non è un problema di tecnologia. È un problema di responsabilità. E ha una soluzione semplice.
Non è un problema di tecnologia. È un problema di responsabilità. E ha una soluzione semplice.
Nominate presto un responsabile della compliance. Integratela nell’architettura prima di costruire il prodotto. Trattate KYC, AML e sicurezza dei pagamenti come infrastruttura, non come una checklist da riprendere prima del lancio.
Se state sviluppando un prodotto fintech e non sapete dove sono le vostre lacune di compliance, possiamo darci un’occhiata. Abbiamo visto abbastanza codice da sapere dove di solito si nascondono i problemi.
Parlateci del vostro progetto →
Nominate presto un responsabile della compliance. Integratela nell’architettura prima di costruire il prodotto. Trattate KYC, AML e sicurezza dei pagamenti come infrastruttura, non come una checklist da riprendere prima del lancio.
Se state sviluppando un prodotto fintech e non sapete dove sono le vostre lacune di compliance, possiamo darci un’occhiata. Abbiamo visto abbastanza codice da sapere dove di solito si nascondono i problemi.
Parlateci del vostro progetto →
