Case study piattaforma d'investimento
Il problema
Il cliente è un'azienda francese che opera nel settore degli investimenti e voleva una piattaforma all-in-one dove i suoi investitori, sottoposti a onboarding individualmente, potessero seguire l'intero flusso d'investimento in un unico posto: dalla verifica dell'identità (KYC / KYB) alla consultazione delle specifiche opportunità d'investimento rese disponibili per loro (con le relative informazioni), fino alla firma del contratto d'investimento sempre completamente integrato nella piattaforma (embedded signature).
Un altro requisito chiave era il controllo amministrativo. L'accesso alle aziende su cui investire non è mai aperto di default: gli admin possono decidere a quali opportunità dare visibilità a ciascun utente e relativi tipi di azione e commissioni.
Prime valutazioni
La prima decisione riguardava quale CMS usare. In passato avevamo lavorato con strumenti come Strapi su casi d'uso simili, ma questa piattaforma aveva bisogno di qualcosa di più a basso livello e più personalizzabile. Abbiamo quindi optato per Directus, che sembrava l'opzione migliore sotto ogni aspetto. Questo perchè tale CMS include: gestione dei file, gestione atomica dei permessi utente e la capacità di implementare azioni automatiche e guidate dai dati senza scrivere una riga di codice.
La scelta più logica per lo stack tecnologico era Next.js, così che frontend e backend potessero esistere in un unico progetto. Questo si traduce in uno sviluppo più efficiente: il team non deve conoscere più linguaggi, la type safety è inclusa di default e in generale si perde meno tempo in lavoro che non sia l'effettivo sviluppo della piattaforma. Il che si traduce anche in un costo minore per il cliente finale.
Essendo anni che lavoriamo con SQL, abbiamo optato per Supabase come database.
Quindi, lo stack tecnologico si riassume in:
- Directus: il CMS che permette agli admin di creare, modificare, archiviare ed eliminare opportunità d'investimento, gestire gli utenti e archiviare e scaricare file, il tutto direttamente dall'interfaccia, senza una riga di codice.
- Supabase: il database Postgres a cui Directus si connette.
- Next.js: per costruire il frontend e interagire con Directus.
Modus Operandi
Conclusa la fase di design, rimane la fase di sviluppo, che abbiamo affrontato nell'ordine sopra elencato.
Per prima cosa, abbiamo predisposto due ambienti separati: pre-produzione (pre-prod) e produzione (prod). Ogni istanza Directus aveva il relativo dominio, così come ogni web app. Questo è stato estremamente semplice da configurare e ci ha permesso di continuare a sviluppare e rilasciare nuove funzionalità in modo pulito, senza interferire con l'ambiente live con utenti reali.
Non abbiamo incontrato particolari ostacoli, lo stack tecnologico era completamente in nostro favore. Da Vercel (infrastruttura dove il codice è hostato) al frontend.
La funzionalità più interessante è stata dare a un utente la possibilità di avere sotto-utenti. L'obiettivo originale era consentire a un singolo account personale di possedere più account business. Dopo aver soppesato alcuni approcci, abbiamo scoperto che la soluzione migliore non era combattere Directus, ma usarlo a nostro vantaggio.
Directus accetta solo indirizzi email formattati in modo convenzionale, quindi non potevamo utilizzare indirizzi email arbitrari. Abbiamo invece codificato le informazioni di cui avevamo bisogno direttamente dentro l'indirizzo, utilizzando il seguente pattern:
<email_base>.<strainga_comune_per_identificare_subuser>.<nome_del_profilo>.com
<email_base>: l'account principale a cui il sotto-utente appartiene.<strainga_comune_per_identificare_subuser>: una stringa fissa, identica per ogni sotto-utente.<nome_del_profilo>: il nome che l'utente ha assegnato a quel sotto-utente.
Dal solo indirizzo potevamo poi ricavare tutti e tre gli elementi: che si tratta di un sotto-utente, a quale profilo fa capo e il suo nome personalizzato. Il tutto restando all'interno di un formato che Directus avrebbe poi accettato.
Una volta costruita la piattaforma di base, abbiamo iniziato a realizzare le funzionalità aggiuntive. Le notifiche via email ne sono l'esempio perfetto. In base a ogni azione ritenuta importante dell'utente, come login, interesse inviato, investimento effettuato, e così via, grazie a Directus abbiamo fatto in modo che l'utente ricevesse anche un feedback via email grazie al quale potesse poi tornare sul sito e fosse al corrente di eventuali tempistiche da aspettare e azioni da effettuare da parte sua o dello staff di Valeureux.
Cambiamenti
Sono state apportate diverse modifiche al design originale. La più significativa è stata l'aggiunta di una dashboard per admin, che dà agli amministratori un luogo dove compiere azioni chiave: inviare promemoria via email, consultare documenti e visualizzare informazioni aggregate su un utente e i suoi sotto-account.
Team
L'intero progetto è stato realizzato prima che NFW Web Studio esistesse. Nonostante ciò, entrambi gli sviluppatori dell'attuale team sono stati coinvolti. Il web design è stato interamente curato internamente, con alcuni elementi, in particolare la palette di colori e i font, specificati dal cliente a partire dal suo design system esistente.
I numeri
Nel corso della vita della piattaforma, gli investitori sono cresciuti e oggi si attestano intorno ai 150, Valeureux gestisce più di 4M€ di asset, su 35 diverse opportunità d'investimento e 27 ruoli utente unici.
Lighthouse / Speed Insights
Data la natura di questa piattaforma, il punteggio di Speed Insights non è significativo, la quasi totalità della piattaforma è protetta da login e altamente personalizzata in base all'utente che la visita.
Questo non significa che abbiamo ignorato le prestazioni, anzi, abbiamo minimizzato le chiamate bloccanti tra frontend e backend incorporando tutto ciò che serve a comprendere i permessi e i dati di un utente in maniera sicura ed efficiente in quella che viene chiamata: "sessione". Quei dati sono poi disponibili senza chiamate al backend aggiuntive. La difficoltà principale è che il token dell'utente deve essere mantenuto costantemente aggiornato.
Lezioni apprese
Questo è un progetto attivamente sviluppato e gestito. È iniziato a novembre 2024 con una v1 (non trattata in questo case study), è migrato alla v2 a gennaio 2025 ed è stato sviluppato continuativamente da allora. È uno dei progetti più estesi e ricchi di funzionalità su cui abbiamo mai lavorato, e siamo grati che Valeureux ci abbia dato la possibilità di lavorare su un qualcosa di tale dimensione.
Se potessimo fare le cose diversamente, avremmo implementato fin dalle prime funzionalità anche i relativi test. Questo perché abbiamo rilasciato le prime versioni, appunto, senza test automatici. Con un numero di funzionalità piccolo e contenuto sembrava una scelta ragionevole ma, man mano che le funzionalità aumentavano, verificare tutto a mano a ogni aggiornamento è diventato ingestibile, e un controllo manuale inevitabilmente si lascia sfuggire qualcosa. Il risultato è stato che, nei suoi primi mesi, la piattaforma non era sempre stabile: mai completamente offline, ma con singole funzionalità che occasionalmente non si comportavano come previsto, il che ha reso l'esperienza iniziale meno coerente di quanto avrebbe dovuto essere.
Test automatici che coprano ciascun flusso principale, login, il flusso d'investimento, upload e download dei documenti e tutto il resto, avrebbero dovuto essere presenti dal primo giorno. L'instabilità è emersa solo mentre la base utenti era piccola e la piattaforma era nelle sue primissime fasi. La lezione che ne abbiamo tratto si applica a tutto quello che ora sviluppiamo.