Pretto: hur man väljer mellan bygga och köpa för att skala effektivt

Pretto är en fransk fintech specialiserad på bolåneförmedling. Sedan starten för 8 år sedan har företaget i hög grad förändrat spelreglerna i en starkt reglerad sektor genom att erbjuda ett 100 % digitalt tillvägagångssätt. Och 2021 nåddes en ny milstolpe med lanseringen av ett nätverk av oberoende agenter.

I dag är verksamheten uppdelad mellan kunder som betjänas på distans och de som stöds av de 300 anslutna agenterna. Denna utveckling har byggt på en central utmaning: att erbjuda en effektiv, modern och enhetlig verktygslåda. En strategisk fråga uppstod därför snabbt: bör vi bygga dessa verktyg internt eller förlita oss på befintliga externa lösningar? I dag bjuder vi in dig att ta del av intervjun med François Sevaistre, CTO på Pretto.

I en fintech som Pretto, där reglering och hastighet i genomförandet är nyckeln, vilka kriterier styr dina val mellan build och buy?

François Sevaistre: Vi återkommer alltid till två enkla kriterier:

1. Är komponenten i fråga en värdekoppling vi ger direkt till våra kunder?
2. Påverkar den vår varumärkesimage och användarupplevelse?

När svaret är ja föredrar vi att bygga.

Så var fallet med vår CRM. Vi ville erbjuda en enhetlig och modern användarupplevelse. Vad gäller agenten måste de kunna hantera sina kunder, följa upp sina prospects, bygga sina ärenden... och allt detta i ett sammanhängande produktuniversum med enkel ergonomi. Om vi hade köpt en extern lösning som SugarCRM eller ytterligare anpassat Salesforce skulle vi ha haft en växande rörlig kostnad med nätverket och ett starkt beroende av en begränsad miljö.

Vi hade redan anpassat Salesforce kraftigt, och vi visste att vi ändå var tvungna att skriva specifik kod. Under dessa förhållanden var det bättre att bygga hemma, i vår logik, snarare än att stapla tredjepartslösningar.

Slutligen fanns det ett långsiktigt finansiellt problem: i början kostar build mer än en SaaS-licens, men när investeringen är gjord jämnas kostnaderna ut och minskar när verksamheten skalas.

Hade detta organisatoriska val en inverkan på dina techteam?

François Sevaistre: Ja, och det är till och med centralt i vår filosofi. Vi är ett litet techteam. Vi har alltid velat förbli kompakt, med utvecklare ansvariga för en hel del av stacken.

När vi beslutade att bygga vår CRM rekryterade jag en chef och två ingenjörer: de hade fullt ansvar för denna komponent. Deras uppdrag gick från design till leverans, inklusive tekniska val. Denna modell för bemyndigande förändrar allt: de är inte enkla "ärendetagare", utan ingenjörer som förstår behoven, deltar i diskussioner med produkt och design, och föreslår de bästa lösningarna.

Det är en viktig faktor för att behålla personal. En utvecklare som bara utför blir trött och slutar. Å andra sidan ser en ingenjör som identifieras som ansvarig för ett perimeter sin konkreta inverkan på verksamheten. Det är mycket mer givande.

Konkret, hur fattades beslutet?

François Sevaistre: Det gjordes i två steg. Först: bör vi köpa eller bygga? Detta första steg involverade alla: verksamhet, produkt, tech, design... och till och med framtida användare, agenterna. Vi utbytte med dem för att förstå deras förväntningar och prioritera behov. Deras engagemang stärkte relevansen av vårt val.

Sedan, när beslutet att bygga var fattat, var vi tvungna att besluta om den tekniska stacken. Där var det ett rent teknikval, med riktlinjen: bygg något enkelt, lätt och underhållbart.

Tre år senare, vad är din bedömning?

François Sevaistre: Bedömningen är positiv. I dag arbetar mer än 300 agenter dagligen med detta verktyg. Det är bokstavligen deras försörjning, eftersom de bara är betalda på provision. Det var därför avgörande att verktyget var robust, pålitligt och ergonomiskt.

Vi fortsätter att utveckla det, och integrerar till exempel AI-baserade funktioner. Men vi uppmärksammar alltid en sak: en funktion, hur imponerande den än är, är värdelös om den inte används. Den verkliga utmaningen är att placera funktioner på rätt plats så att deras adoption är naturlig.

Finansiellt sett är det tydligt att vi i detta skede har betalat mer än om vi hade tagit Salesforce-licenser. Men användarupplevelsen är mycket bättre, och adoptionen ojämförbar. När du rekryterar mäklare som tidigare arbetade med papper och penna är varje timme sparad på utbildning värd sin vikt i guld.

Omvänt, vilka komponenter anser du vara icke-differentierande och därmed outsourcningsbara?

François Sevaistre: Det finns flera.

• AI: vi tränar inte vår egen LLM, det är inte vår verksamhet. För att hantera våra prompter och deras versionshantering använder vi Langfuse.

• Datapipeline: vi har Segment för att samla in och omfördela användarhändelser. För tillfället köper vi, men med tanke på kostnaden funderar vi på att internalisera det.

• E-post: vi använder fortfarande en del av Salesforce för att dirigera e-post till rätt kunder. Det är dyrt, och troligtvis ämnat att byggas om internt.

Sammanfattningsvis kan allt som inte direkt ger differentierande värde till våra kunder köpas.

Vilket råd skulle du ge en CTO som tvekar mellan build och buy?

François Sevaistre: Varje kodrad du skriver är underhållsskuld. Så om du kan outsourca, gör det. Buy är ett utmärkt sätt att snabbt testa ett användningsfall. Om det inte fungerar är det enkelt att byta.

Den verkliga fällan är att bygga för tidigt. När du väl har investerat internt försvarar du din lösning även om den inte längre matchar behoven. Medan du med en köpt lösning behåller friheten att pivotera.

Mitt råd: börja med att köpa, validera behovet, bygg sedan bara det som verkligen är strategiskt för din verksamhet.