Doolta
EN · FR Write to us

Arnaud ASSAD, founder of Doolta

I start by understanding the system. The tool comes last.

You don’t hire me for a technology. You hire me to turn a tangled problem, where code, architecture, business constraints and organisation feed into each other, into a few clear decisions your team can hold on to without me.

Arnaud ASSAD

Arnaud ASSAD

Senior technical expert and Fractional CTO. 25 years of Perl, C, Go, distributed systems and the teams that run them.

25+

years on production systems

9am-1pm

CET overlap window

24 h

response time

How I think

Four steps, always in this order.

Most engagements that go wrong reverse this order: they start from the tool, then look for the problem it solves. I do the opposite, and that is what makes a decision still defensible six months later.

  1. 01

    Systems thinking

    A symptom is almost never its own cause. I look at the whole system: the code, but also the data flows, the business constraints, the team’s habits and what the organisation quietly rewards. Many failures that look technical are coupling failures.

  2. 02

    Clarification

    I reduce the problem until it becomes falsifiable. What has to stay true? What is allowed to break? What question do you actually want answered? Until that is stated, any solution is a bet. This step is often the one that unblocks the work, before a single line of code.

  3. 03

    Solution

    I look for the simplest structure that holds. Not the most elegant or the most modern one: the one your teams can operate, debug and evolve once I am gone. A solution you cannot maintain is not a solution.

  4. 04

    Tools

    The tool comes last, and only if the three previous steps justify it. Go, PostgreSQL, ClickHouse, Docker, HTMX, a single binary or a forty-line script: the choice follows from the problem, never the other way round. Sometimes the right answer is to add nothing at all.

The deliberate corollary: I sometimes conclude that a problem is not technical. That can be the most profitable outcome of an audit, and it is also the one few providers are willing to put in writing.

Three examples

The same method, on three unrelated problems.

All three systems are public: code, tests, architecture decisions and stated limits. You can judge the work before trusting me with yours.

mAPI-ng

Incident diagnosis for Go APIs

The system
An API slows down in production. The observability stack in place shows everything and explains nothing: on every incident the team spends its time reading graphs instead of fixing things.
The clarification
The real question is not “what do the metrics show?” but “what is the most likely cause, and what would rule it out?”. A diagnosis with no refutation criterion is just a well-presented opinion.
The solution
Classify causes into eight families, and never propose one without the evidence supporting it and the line stating what would prove it wrong. When nothing explains the anomaly, say so: “cause not attributed”, rather than invent a reassuring story.
The tool
Only then the tooling: in-process DDSketch aggregation, compact summaries in ClickHouse, one environment variable to instrument. The architecture follows from the reasoning, not from a stack preference.
See the project →

YVO Cloud

Self-hosted personal cloud

The system
File storage with blob-level deduplication. Technically sound, measurable, efficient, and already running.
The clarification
One non-negotiable requirement was still not met: getting your files back without the application. The system worked, but it did not keep its promise. No metric surfaces that distinction.
The solution
Challenge the architecture that works. New principle: the truth lives on disk, every current file stays readable and intact at its real path, history becomes a side delta.
The tool
The change is recorded as a documented architecture decision with its full rationale, like the eight others in the project. Knowing how to dismantle what you built is part of the job.
See the project →

AXF

Open format for digital identities

The system
Juggling an employer, freelance clients and personal projects: ~/.ssh/config rules, an overloaded .gitconfig to avoid committing with the wrong email, separate browser windows. Everyone works around it with their own scripts.
The clarification
These are not five independent tooling problems. It is one problem nobody had named: identity context switching.
The solution
Give that problem an explicit model: one command to enter a context, one to leave it cleanly. No daemon, no hidden state, identities stored as versionable documents.
The tool
An open specification rather than yet another in-house script, on the model of OpenAPI or OCI: the format first, the reference Go implementation second. A problem named properly gets solved once.
See the project →

Why hire me

Because the value of an engagement is not measured by the volume of code delivered, but by what your team can do on its own the day I leave.

  • I ship all the way. Moontill, the point-of-sale system I designed and built, takes the real daily sales of an independent shop, backup, rollback and operator runbook included. I know the trade-offs of going to production, I don’t just recommend them.

  • I make the system legible. Documented decisions, readable architecture, reduced bus factor: nothing I build should depend on my being there.

  • I measure instead of asserting. Locked test coverage, compression gains benchmarked on real repositories, retrieval accuracy evaluated: my claims are verifiable, including when they are inconvenient for me.

  • I state the limits. Pre-alpha status announced, draft specification acknowledged, incident cause left unattributed when it is. You will always know where a project actually stands.

  • You judge on evidence. The systems I build are public: code, tests, decisions and blind spots.