From 0 to 50k Customers: What I Learned Building Orus's Product

May 2022. I've been at Orus for about two weeks, and it's the day after we signed our first customer. We run into our first real business problem: our customer made a mistake on one of the details, and we need to process an endorsement to their contract.

The catch: at that point, nothing had been built for it. No screen, no data model, no business logic. Just a customer who needed to change what they'd just subscribed to, and a small team improvising the feature in real time. Years later, it's one of the core features of our product, and one I still own with my squad today.

That story sums up what this whole journey has been like for me: every new customer brought its own use case, and we built the product day after day, client after client. The company's growth didn't follow the product. It drove it, and I was lucky enough to have a front-row seat.

The early days, from the inside

It all started with a LinkedIn message, a bit like a message in a bottle, sent by Samuel, our CTO, four and a half years ago now. The company itself just turned 5. I was the first person hired on the team, though the second to actually show up in person.

When I joined, there was already a codebase for an insurance product we hadn't sold yet. The week I arrived actually marked a first: Samuel completed the very first subscription flow with payment, for the grand sum of €2.50. A test, but a real one, with an actual payment going through. I remember that moment well: proof that everything we'd built in a vacuum actually worked.

There were three of us on the team. Safe to say we were starting from pretty much nothing, with very little certainty about what would actually work.

The moments that changed everything

"Every customer brought its own use case, and we built the product day after day."

The first customer, and that contract endorsement story the very next day. In the moment, it felt like a one-off problem to solve under pressure, with whatever we had on hand. In hindsight, it was the birth of contract management: one of the most foundational features of the product, and the most important thing in insurance underwriting. It has been picked up and iterated on more times than one can count through the years, and I still lead on this subject today with my squad. That first-day emergency became, years later, my everyday work.

"We weren't patching together a product anymore, we were building a platform."

The real turning point, for me, came with the launch of our second product. Up until then, we could pass for a company that had managed to ship one insurance product. With this one, we proved something else: we were capable of shipping multiple products, across multiple insurance verticals, with the same team and the same technical foundation. That's the moment that really laid the groundwork for what Orus would become. It's also when I felt my role start to shift: we weren't patching together a product anymore, we were building a platform.

The third key moment was building a custom framework designed to let us adapt to any insurance product or need. Instead of rebuilding business logic from scratch for every new product or every new regulatory quirk, we gave ourselves the ability to configure it instead. That framework is what lets us ship a new insurance product today without starting from zero each time. That shift was just as important as the second product release, if not more, even if it's far less visible from the outside.

We learned from each of these moments, often the hard way, and mostly came out ahead.

What we learned along the way

"Craft practices, chosen at the right moment, took us further than a doctrine applied on principle."

Following the business instead of enforcing practices from day one saved us from a lot of dead ends. We stayed very close to the YAGNI, DRY and SOLID principles: never build more than what you actually need while doing it the smartest way possible. We could have, for instance, tried to apply DDD "by the book" from the start, with its whole toolbox. Instead, we let the nature of the insurance business itself guide us toward the right abstractions, right when we actually needed them.

Our dimension framework (this one might deserve its own article!) is a good example of that: it's by following the concrete needs of the product, rather than a technical dogma, that we ended up building what is today a far more advanced take on the value objects so dear to DDD. Craft practices, chosen at the right moment rather than enforced too early, took us further than a doctrine applied on principle.

"An AI agent reading the code immediately understands what it's about."

No tech blog post in 2026 is complete without a word on AI, so here it is. This organic approach, driven by the business rather than by theory, had an effect we hadn't really anticipated: it makes the code far more legible for LLMs and AI agents. Every abstraction directly reflects a business concept rather than a pattern bolted on by principle. So an agent reading the code immediately understands what it's about, without having to decode an extra layer of indirection. In practice, that translates into far more relevant code suggestions and code-review feedback than usual. And the test suggestions, on this kind of codebase, are honestly impressive.

The main criticism you could level at how we do things is that we're always a step behind, that we wait for problems to show up in production before acting. That's not quite how we see it. The moment we spot even a hint of smoke, we mobilize to identify and fix the root cause. We'd rather respond deliberately to real problems than build prevention for problems we haven't run into yet.

Where we stand today

A dozen insurance products launched in 3 countries and 4 languages later, we're now 18 people on the tech team. I lead the Insurance Factory squad, which designs and ships our insurance products, alongside 6 developers and a PM.

Looking back at that €2.50 payment from when I joined, and at the 50,000 customers Orus counts today, what strikes me most is that the method hasn't changed: we keep building product after product, client after client, trying to keep things as simple as possible. It's probably the only real recipe we've found, and I'm glad we've followed it since day one.

We're more SOLID today than we've ever been (pun intended). But if these past four years mean anything, it's mostly a reminder that we haven't seen anything yet compared to what we're capable of building tomorrow.