Pretto: How to decide between build and buy to scale effectively

Pretto is a French fintech specialized in mortgage brokerage. Since its creation 8 years ago, it has largely disrupted the codes of a highly regulated sector by offering a 100% digital approach. And in 2021, a new milestone was reached with the launch of a network of independent agents.

Today, the activity is split between clients served remotely and those supported by the 300 affiliated agents. This development has relied on a central challenge: offering an efficient, modern and unified suite of tools. A strategic question therefore quickly arose: should we build these tools internally, or rely on existing external solutions? Today, we invite you to discover the interview with François Sevaistre, CTO of Pretto.

In a fintech like Pretto, where regulation and speed of execution are key, what criteria guide your choices between build and buy?

François Sevaistre: We always come back to two simple criteria:

1. Is the component in question a value link that we bring directly to our customers?
2. Does it impact our brand image and user experience?

When the answer is yes, we prefer to build.

This was the case with our CRM. We wanted to offer a unified and modern user experience. As for the agent, they must be able to manage their clients, follow their prospects, build their files... and all this in a coherent product universe, with simple ergonomics. If we had bought an external solution like SugarCRM or further customized Salesforce, we would have had a growing variable cost with the network and a strong dependence on a constrained environment.

We had already heavily customized Salesforce, and we knew we would have to write specific code anyway. Under these conditions, it was better to build at home, in our logic, rather than stacking third-party solutions.

Finally, there was a long-term financial issue: at the beginning, build costs more than a SaaS license, but once the investment is made, costs are smoothed and decrease as the activity scales.

Did this organizational choice have an impact on your tech teams?

François Sevaistre: Yes, and it's even central to our philosophy. We are a small tech team. We have always wanted to stay tight, with developers responsible for an entire piece of the stack.

When we decided to build our CRM, I recruited a manager and two engineers: they had full responsibility for this component. Their mission went from design to delivery, including technical choices. This empowering model changes everything: they are not simple "ticket takers", but engineers who understand the needs, participate in discussions with product and design, and propose the best solutions.

It's an important retention factor. A developer who only executes ends up getting tired and leaving. On the other hand, an engineer who is identified as responsible for a perimeter sees their concrete impact on the business. It's much more rewarding.

Concretely, how was the decision made?

François Sevaistre: It was done in two stages. First, should we buy or build? This first step involved everyone: business, product, tech, design... and even future users, the agents. We exchanged with them to understand their expectations and prioritize needs. Their involvement reinforced the relevance of our choice.

Then, once the decision to build was made, we had to decide on the technical stack. There, it was a purely tech choice, with the guideline: build something simple, light and maintainable.

Three years later, what is your assessment?

François Sevaistre: The assessment is positive. Today, more than 300 agents work daily with this tool. It's literally their livelihood, since they are only paid on commission. It was therefore vital that the tool be robust, reliable and ergonomic.

We continue to evolve it, integrating for example AI-based features. But we always pay attention to one thing: a feature, however impressive it may be, is useless if it's not used. The real challenge is to place features in the right place so that their adoption is natural.

Financially, it's clear that at this stage we have paid more than if we had taken Salesforce licenses. But the user experience is much better, and adoption incomparable. When you recruit brokers who previously worked with paper and pencil, every hour saved on training is worth its weight in gold.

Conversely, which components do you consider non-differentiating and therefore externalizable?

François Sevaistre: There are several.

• AI: we don't train our own LLM, it's not our business. To manage our prompts and their versioning, we use Langfuse.

• Data pipeline: we have Segment to collect and redistribute user events. For now, we buy, but given the cost, we're thinking about internalizing it.

• Emailing: we still use a piece of Salesforce to route emails to the right customers. It's expensive, and probably destined to be rebuilt internally.

In summary, everything that doesn't directly bring differentiating value to our customers can be bought.

What advice would you give to a CTO who hesitates between build and buy?

François Sevaistre: Every line of code you write is maintenance debt. So if you can outsource, do it. Buy is an excellent way to quickly test a use case. If it doesn't work, it is easy to change.

The real trap is building too early. Once you've invested internally, you defend your solution even if it no longer matches the needs. Whereas with a purchased solution, you keep the freedom to pivot.

My advice: start by buying, validate the need, then only build what is really strategic for your business.