Pretto: cómo decidir entre build y buy para escalar de forma eficaz

Pretto es una fintech francesa especializada en intermediación hipotecaria. Desde su creación hace 8 años, ha transformado profundamente los códigos de un sector altamente regulado ofreciendo un enfoque 100 % digital. Y en 2021 se alcanzó un nuevo hito con el lanzamiento de una red de agentes independientes.

Hoy, la actividad se divide entre clientes atendidos de forma remota y los apoyados por los 300 agentes afiliados. Este desarrollo se ha apoyado en un desafío central: ofrecer una suite de herramientas eficiente, moderna y unificada. Por ello, rápidamente surgió una pregunta estratégica: ¿debemos construir estas herramientas internamente, o apoyarnos en soluciones externas existentes? Hoy les invitamos a descubrir la entrevista con François Sevaistre, CTO de Pretto.

En una fintech como Pretto, donde la regulación y la velocidad de ejecución son clave, ¿qué criterios guían sus decisiones entre build y buy?

François Sevaistre: Siempre volvemos a dos criterios sencillos:

1. ¿El componente en cuestión es un eslabón de valor que aportamos directamente a nuestros clientes?
2. ¿Impacta en nuestra imagen de marca y experiencia del usuario?

Cuando la respuesta es sí, preferimos construir.

Ese fue el caso de nuestro CRM. Queríamos ofrecer una experiencia de usuario unificada y moderna. En cuanto al agente, debe poder gestionar sus clientes, hacer seguimiento de sus prospectos, preparar sus expedientes... y todo esto en un entorno de producto coherente, con una ergonomía sencilla. Si hubiéramos comprado una solución externa como SugarCRM o personalizado aún más Salesforce, habríamos tenido un coste variable creciente con la red y una fuerte dependencia de un entorno restrictivo.

Ya habíamos personalizado mucho Salesforce y sabíamos que tendríamos que escribir código específico de todas formas. En esas condiciones, era mejor construir en casa, con nuestra propia lógica, en lugar de apilar soluciones de terceros.

Por último, había una cuestión financiera a largo plazo: al principio, build cuesta más que una licencia SaaS, pero una vez realizada la inversión, los costes se suavizan y disminuyen a medida que la actividad escala.

¿Esta decisión organizativa tuvo impacto en sus equipos tecnológicos?

François Sevaistre: Sí, y es incluso central en nuestra filosofía. Somos un equipo tecnológico pequeño. Siempre hemos querido mantenernos compactos, con desarrolladores responsables de una parte completa del stack.

Cuando decidimos construir nuestro CRM, contraté a un manager y dos ingenieros: tuvieron plena responsabilidad sobre este componente. Su misión iba desde el diseño hasta la entrega, incluidas las decisiones técnicas. Este modelo de empoderamiento lo cambia todo: no son simples "tomadores de tickets", sino ingenieros que comprenden las necesidades, participan en las discusiones con producto y diseño, y proponen las mejores soluciones.

Es un factor importante de retención. Un desarrollador que solo ejecuta acaba cansándose y marchándose. En cambio, un ingeniero identificado como responsable de un perímetro ve su impacto concreto en el negocio. Es mucho más gratificante.

Concretamente, ¿cómo se tomó la decisión?

François Sevaistre: Se hizo en dos etapas. Primero, ¿compramos o construimos? Este primer paso involucró a todos: negocio, producto, tecnología, diseño... e incluso a los futuros usuarios, los agentes. Intercambiamos con ellos para entender sus expectativas y priorizar necesidades. Su participación reforzó la pertinencia de nuestra elección.

Después, una vez tomada la decisión de construir, había que decidir el stack técnico. Ahí fue una elección puramente técnica, con la directriz: construir algo sencillo, ligero y mantenible.

Tres años después, ¿cuál es su balance?

François Sevaistre: El balance es positivo. Hoy, más de 300 agentes trabajan diariamente con esta herramienta. Es literalmente su medio de vida, ya que solo cobran por comisión. Era por tanto vital que la herramienta fuera robusta, fiable y ergonómica.

Seguimos evolucionándola, integrando por ejemplo funcionalidades basadas en IA. Pero siempre prestamos atención a una cosa: una funcionalidad, por impresionante que sea, es inútil si no se usa. El verdadero desafío es colocar las funcionalidades en el lugar correcto para que su adopción sea natural.

Financieramente, está claro que en esta etapa hemos pagado más que si hubiéramos tomado licencias de Salesforce. Pero la experiencia del usuario es mucho mejor, y la adopción incomparable. Cuando se reclutan agentes que antes trabajaban con papel y lápiz, cada hora ahorrada en formación vale su peso en oro.

Por el contrario, ¿qué componentes considera no diferenciadores y por tanto externalizables?

François Sevaistre: Hay varios.

• IA: no entrenamos nuestro propio LLM, no es nuestro negocio. Para gestionar nuestros prompts y su versionado, usamos Langfuse.

• Pipeline de datos: tenemos Segment para recopilar y redistribuir eventos de usuario. Por ahora compramos, pero dado el coste, estamos pensando en internalizarlo.

• Email: seguimos usando una parte de Salesforce para enrutar correos a los clientes correctos. Es caro, y probablemente destinado a reconstruirse internamente.

En resumen, todo lo que no aporta valor diferenciador directamente a nuestros clientes puede comprarse.

¿Qué consejo daría a un CTO que duda entre build y buy?

François Sevaistre: Cada línea de código que escribe es deuda de mantenimiento. Por tanto, si puede externalizarlo, hágalo. Buy es una excelente forma de probar rápidamente un caso de uso. Si no funciona, es fácil cambiar.

La verdadera trampa es construir demasiado pronto. Una vez que ha invertido internamente, defiende su solución aunque ya no corresponda a las necesidades. En cambio, con una solución comprada, conserva la libertad de pivotar.

Mi consejo: empiece comprando, valide la necesidad, y solo entonces construya lo que es realmente estratégico para su negocio.