NUOVOModifica nel contesto i testi della Sua app con la nostra estensione Chrome
DocumentazioneAccedi
Logo di Prismy
Perché Prismy?
Prodotto
Risorse
Prezzi
DemoProva gratuita

2 ottobre 2025 · Intervista

Pretto: come decidere tra build e buy per scalare efficacemente

François Sevaistre, CTO di Pretto, condivide i criteri decisionali per scegliere tra sviluppo interno e soluzioni di terze parti in una fintech regolamentata.

Pretto: come decidere tra build e buy per scalare efficacemente

Pretto è una fintech francese specializzata nella mediazione creditizia. Dalla sua creazione, 8 anni fa, ha largamente trasformato i codici di un settore altamente regolamentato offrendo un approccio 100% digitale. Nel 2021 è stato raggiunto un nuovo traguardo con il lancio di una rete di agenti indipendenti.

Oggi l'attività si divide tra clienti seguiti da remoto e quelli supportati dai 300 agenti affiliati. Questo sviluppo si è basato su una sfida centrale: offrire una suite di strumenti efficiente, moderna e unificata. È emersa rapidamente una domanda strategica: costruire questi strumenti internamente, o affidarsi a soluzioni esterne esistenti? Oggi vi invitiamo a scoprire l'intervista con François Sevaistre, CTO di Pretto.

In una fintech come Pretto, dove regolamentazione e velocità di esecuzione sono fondamentali, quali criteri guidano le vostre scelte tra build e buy?

François Sevaistre: Torniamo sempre a due criteri semplici:

  1. Il componente in questione è un anello di valore che portiamo direttamente ai nostri clienti?
  2. Impatta la nostra immagine di brand e l'esperienza utente?

Quando la risposta è sì, preferiamo costruire.

È stato il caso del nostro CRM. Volevamo offrire un'esperienza utente unificata e moderna. Quanto all'agente, deve poter gestire i propri clienti, seguire i propri prospect, costruire i propri dossier, e tutto questo in un universo di prodotto coerente, con un'ergonomia semplice. Se avessimo acquistato una soluzione esterna come SugarCRM o ulteriormente personalizzato Salesforce, avremmo avuto un costo variabile crescente con la rete e una forte dipendenza da un ambiente vincolato.

Avevamo già personalizzato pesantemente Salesforce e sapevamo che avremmo comunque dovuto scrivere codice specifico. In queste condizioni, era meglio costruire in casa, nella nostra logica, piuttosto che impilare soluzioni di terze parti.

Infine, c'era una questione finanziaria a lungo termine: all'inizio, costruire costa più di una licenza SaaS, ma una volta effettuato l'investimento, i costi si livellano e diminuiscono con la crescita dell'attività.

Questa scelta organizzativa ha avuto un impatto sui vostri team tech?

François Sevaistre: Sì, ed è addirittura centrale nella nostra filosofia. Siamo un piccolo team tech. Abbiamo sempre voluto rimanere snelli, con developer responsabili di un'intera parte dello stack.

Quando abbiamo deciso di costruire il nostro CRM, ho assunto un manager e due ingegneri: avevano la piena responsabilità di questo componente. La loro missione andava dalla progettazione alla consegna, incluse le scelte tecniche. Questo modello responsabilizzante cambia tutto: non sono semplici "esecutori di ticket", ma ingegneri che capiscono le esigenze, partecipano alle discussioni con il prodotto e il design, e propongono le migliori soluzioni.

È un importante fattore di fidelizzazione. Un developer che si limita a eseguire finisce per stancarsi e andarsene. Un ingegnere identificato come responsabile di un perimetro vede invece il proprio impatto concreto sul business. È molto più gratificante.

Concretamente, come è stata presa la decisione?

François Sevaistre: Si è svolta in due fasi. Prima: acquistare o costruire? Questa prima fase ha coinvolto tutti: business, prodotto, tech, design, e persino i futuri utenti, gli agenti. Abbiamo dialogato con loro per capire le loro aspettative e dare priorità alle esigenze. Il loro coinvolgimento ha rafforzato la pertinenza della nostra scelta.

Poi, una volta presa la decisione di costruire, abbiamo dovuto scegliere lo stack tecnico. Lì era una scelta puramente tech, con la linea guida: costruire qualcosa di semplice, leggero e manutenibile.

Tre anni dopo, qual è il vostro bilancio?

François Sevaistre: Il bilancio è positivo. Oggi, più di 300 agenti lavorano quotidianamente con questo strumento. È letteralmente il loro mezzo di sostentamento, dato che vengono pagati solo a provvigione. Era quindi vitale che lo strumento fosse robusto, affidabile ed ergonomico.

Continuiamo a farlo evolvere, integrando ad esempio funzionalità basate sull'IA. Ma prestiamo sempre attenzione a una cosa: una funzionalità, per quanto impressionante, è inutile se non viene usata. La vera sfida è collocare le funzionalità nel posto giusto affinché la loro adozione sia naturale.

Finanziariamente, è chiaro che a questo stadio abbiamo pagato di più rispetto all'acquisto di licenze Salesforce. Ma l'esperienza utente è molto migliore e l'adozione è incomparabile. Quando si assumono mediatori che lavoravano in precedenza con carta e matita, ogni ora risparmiata in formazione vale il suo peso in oro.

Al contrario, quali componenti considerate non differenzianti e quindi esternalizzabili?

François Sevaistre: Ce ne sono diversi.

  • IA: non alleniamo il nostro LLM, non è il nostro core business. Per gestire i nostri prompt e il loro versionamento, usiamo Langfuse.

  • Pipeline dati: abbiamo Segment per raccogliere e ridistribuire gli eventi utente. Per ora acquistiamo, ma visto il costo, stiamo pensando di internalizzarlo.

  • Emailing: utilizziamo ancora una parte di Salesforce per instradare le email ai clienti giusti. È costoso, e probabilmente destinato a essere ricostruito internamente.

In sintesi, tutto ciò che non porta direttamente valore differenziante ai nostri clienti può essere acquistato.

Che consiglio dareste a un CTO che esita tra build e buy?

François Sevaistre: Ogni riga di codice che scrivete è debito di manutenzione. Quindi, se potete esternalizzare, fatelo. Acquistare è un ottimo modo per testare rapidamente un caso d'uso. Se non funziona, è facile cambiare.

La vera trappola è costruire troppo presto. Una volta che avete investito internamente, difendete la vostra soluzione anche se non corrisponde più alle esigenze. Con una soluzione acquistata, invece, mantenete la libertà di cambiare direzione.

Il mio consiglio: iniziate acquistando, validate l'esigenza, poi costruite solo ciò che è davvero strategico per il vostro business.

Newsletter.title.Intervista

Riceva le ultime novità su localizzazione, traduzioni con IA e aggiornamenti di prodotto direttamente nella Sua casella di posta.

Niente spam, annulli l'iscrizione in qualsiasi momento. Rispettiamo la Sua privacy.

Logo di Prismy

Vai globale, in modo semplice e potente.

Prismy - Localizzazione nativa GitHub con IA per team di sviluppo e prodotto | Product Hunt

Per sviluppatori

integrazione GitHubintegrazione GitLabCLI

© 2026 Prismy. Tutti i diritti riservati.

TerminiPrivacy
Prismy