Skip to content
Youness Aamiri

About

I build systems where being wrong is expensive. Five years of production work across fintech and insurance — IFRS9 ECL pipelines, insurance tarification engines, reconciliation systems handling millions of transactions — taught me the same lesson from two directions: correctness and performance aren’t separate concerns you trade off against each other. They’re the same discipline, applied at different scales. A reconciliation engine that’s fast but wrong is worthless. One that’s correct but too slow to run overnight is worthless too. The interesting engineering is never picking one; it’s refusing to accept that you have to.

At Omnishore, I led feature and architecture work on an insurance payment/attestation platform. At B3G, I worked with clients including CIH Bank and Umnia Bank. Along the way: PD/LGD/EAD modeling for IFRS9, Moroccan auto insurance domain logic (garanties, RC, CatNat, bonus-malus/CRM), and enough production incidents to have opinions about both halves of that lesson above.

What I’m building now

Most of my current work is open source, and it’s genuinely one project with two halves: the systems, and the tool that keeps them honest.

The Cedar suite — .NET financial engines:

BenchmarkGate — a local-first performance regression gate for BenchmarkDotNet. This exists because of the CedarRecon work above: once you’ve spent real time proving a performance claim with a benchmark, “eyeball the CI log and hope someone notices” stops being an acceptable way to protect that work going forward. BenchmarkGate turns a BenchmarkDotNet run into a committed, reviewable policy — a baseline and a threshold file in the repo, not a number someone half-remembers — and a CI exit code that actually enforces it.

See the projects page for the full list, or GitHub for everything — stars, issues, and feedback are all welcome.

Stack

Mostly C# and .NET — Clean Architecture, DDD, CQRS, MediatR — with a growing focus on Kubernetes (CKAD certified, working toward CKA and CKS) and cloud infrastructure. I have a strong pull toward distributed systems, enough that I’ve been working through the theory deliberately rather than picking it up incidentally: CAP theorem, vector clocks, Paxos, quorum mechanics. It shows up in practice more than you’d expect — the columnar rewrite in the CedarRecon series is a cache-locality problem, not a distributed-systems one, but it’s the same instinct: understand what kind of cost you’re actually paying before you try to pay less of it.

Where this is going

Longer term, I’m aiming toward a Solutions Architect or Staff Engineer role, with a growing pull toward quantitative finance and trading systems — ML/DL applied to financial domains is a direction I’m actively building toward, not just reading about.

This blog is where I write up the engineering problems worth writing up: performance work, architecture decisions, and the dead ends that taught me as much as the fixes that worked. If a post doesn’t include at least one thing that turned out to be wrong, I probably cut it for being too tidy to be honest.