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.

Dealing with errors is an essential part of software engineering.

Defining and having strong guidelines on how to handle errors will make your life easier when developing features, but also, and maybe more importantly when things go wrong!

At Orus (where we try to reinvent professional insurance), over time, we tailored an error strategy that works well for us and that we think could be useful to share.