Our frontend has grown fast. Along the way we accumulated props drilled several layers deep to reach one leaf, components that fetch data, hold state, and render markup at once, and rows steered by a growing pile of props.

None of this is a disaster. It is just friction, and it compounds. So we made a deliberate call: converge on composition, and treat it as a ladder. You start on the cheapest rung, and you only climb when a concrete pain pushes you up.

This article is about that ladder: how we compose React components, and when each step is worth its cost. The wider story, where the Orus frontend is heading, is for another article.

On our last project, the way we planned, built and reviewed the work changed more than the code itself. AI agents were part of the project from day one, no longer a tool we used from time to time. This post is about that method.

The project was a rebuild of our organizations module, one of the oldest and most central parts of the codebase. It models partners, brokers and their members, and it sits upstream of most of what the platform does. Replacing it had been on the backlog for a while. It was the kind of project that stays "not yet" because the risk surface is high: everything touches it, and touching it wrong has cascading consequences.

We shipped it. We sized it at around 30 working days, shipped in about 20, and every milestone landed ahead of its ETA. But the schedule is not the point. The method is, and it is one we want to apply to all our next projects, not just this one.

Every Orus insurance contract ships with a stack of legal documents: the contract terms, the insurance certificate, invoices, fiscal attestations for tax-deductible contracts. Their format is regulated, their content reviewed by legal counsel, and they're rendered dynamically from subscription data: customer name, company SIREN, coverages, premium, any clauses negotiated for that specific deal.

We add new products every few weeks. At the time of writing this, we render 60 distinct customer-facing document templates across our French and Spanish products. The whole thing is 218 React components.

Adding a new template used to take a couple of days. We've brought it down to a few hours by building a Claude Code skill that handles the tedious parts, with a human still in the loop on every non-trivial decision. This article walks through what the skill does, what we deliberately keep human, and the gotchas baked into it.

In our previous article, we introduced how event sourcing works at Orus. Instead of mutating rows in a database, we append immutable events to an event store. We then derive the current state of any entity (a contract, an invoice, a user, or whatever...) by replaying those events through a reducer.

That covers writing data and reading it. But there's a third thing every real application needs to do: react to what happened.

When a contract is signed, an invoice needs to be generated. When a payment fails, a broker needs to be notified. When a user uploads a document, an AI analysis should kick off. None of that happens by itself just because you appended an event.

This calls for additional infrastructure.

Event sourcing is rarely used as the foundation of the whole system, but at Orus, we had the chance to start from scratch, and think things through before writing the first line of code.

Insurance is complicated, and we need to know exactly what happened at any given time.

When a claim is filed, a contract renewed, or a coverage added, the "current state" of a database row isn't enough. We need to answer: Who changed this? When? Why? And what did the contract look like exactly before that change?

In a standard CRUD application, you might add an audit log table. But audit logs rot. They get out of sync with the actual data. In event sourcing, the audit log is the data.

We decided early on to build our backend (TypeScript/Node.js) on a 100% event sourced architecture. It wasn’t the easiest path, but it was the right one for our domain.

At Orus, we pay a lot of attention to recruiting the right people, and it's been my main priority since the beginning.

To give a bit of transparency to anyone interested in how we work, here are the fundamental guidelines that I follow as a CTO when hiring people.

Hiring a trajectory, not a perfect CV​

Years ago, at Kapten (back when it was still called Chauffeur Privé), I was hired in a way that didn't make a lot of sense on paper. My background wasn't the obvious fit. There were shinier CVs. More traditional paths. Safer bets.

And yet, someone looked at me and thought: this guy can grow into the role. He's curious, fast, hungry. He'll figure it out.

They took the bet. I ran with it. And it shaped how I see hiring forever: the best people are often the ones you can't perfectly describe in a job ad.

So when I'm on the hiring side now, I remind myself: don't just scan for the checklist. Scan for the energy, the capacity to stretch. Because that's where the real leverage is.

At Orus, MongoDB is a cornerstone of our technical stack. Its flexibility, thanks to its document‑oriented model, makes it an excellent choice for quickly modeling complex data. But, as with any powerful tool, that flexibility can become a pitfall if not handled correctly.

Index management, in particular, is still underestimated.

We've all, at some point early in our careers, added an index "just in case," copy‑pasted configuration from a neighboring repository, or assumed MongoDB would "choose the right index" for us. The result: useless indexes, performance regressions, and sometimes even counterproductive setups.

In this article, we share our experience on:

• How MongoDB indexes really work (beyond the documentation)
• Indexing patterns to avoid, even if they seem "safe"
• A clear method to decide when and why to add an index

If you've ever been on duty at a company with a lot of customers and 24/7 activity, chances are that you already found out the hard way what makes an alert actionable.

An alert is actionable when the first person who sees it can immediately answer three questions:

• What broke? – a clear, human‑readable message, making it obvious what the problem is, business wise.
• Where did it break? – for which specific entity(ies) and in which situation the problem happened.
• Why did it break? – whenever possible, the precise error condition that leads to the unexpected situation.

If any of those bullets are missing, the engineer's next best move is usually to add logs, redeploy, and hope the error happens again. That is wasted time.

:::note Scope of this article This article focuses on application-level alerts – errors thrown by your code when business logic fails, and not on infrastructure alerts (CPU usage, disk space, network issues). :::

So how do you make sure your alerts are actionable?

Curiously, dependency injection is not something that we often see in the JavaScript ecosystem.

Still, it's a powerful pattern that can help you make your code more flexible and easier to test, if implemented properly.

After a lot of iterations, we've come up with a dependency injection system that works well for us at Orus. The point of this article is not to cover exactly how dependency injection works, but rather to share our learnings in building it.

Unions and discriminated unions are great tools that can make the code flexible, while keeping the complexity to a low level. But tiny differences in the style of the code that uses them can make the difference between robust code, and bugs waiting to happen.

In this article, we will dive into two patterns that can help us make our code more future-proof.

But before "future-proofing" our code, let's remember that many technical debt nightmares originate from unfortunate attempts to be future-proof.

So let's be clear about what we mean by future-proof code.