Most engineering consultancy websites, ours included until recently, describe the work in words that could mean almost anything. "We enable digital transformation through cloud-native excellence." Nobody knows what that means, including, sometimes, the people who wrote it.
So here is the plain version.
The work
We are a small engineering team in Paris. We do three kinds of work, and they overlap more than they look like they do.
We design and build backend systems. Usually this is a set of services that need to talk to each other reliably, hold state correctly, and not fall over when traffic triples. In practice that means API design, data modelling, queue and workflow design, and the unglamorous decisions about idempotency and retries that determine whether the system is trustworthy at 3am.
We build the machinery that ships them. Pipelines that build, test, scan, sign, and deploy. Infrastructure defined in code so that an environment is a file rather than an afternoon. Monitoring that tells you something is wrong before a customer does. Rollbacks that have actually been rehearsed.
We put machine learning into production and keep it there. Not model research. The part after that: the data pipeline that feeds it, the versioning that lets you reproduce a result from four months ago, the deployment that serves it under load, and the monitoring that catches drift before it quietly degrades for a quarter.
What a project usually looks like
It starts with an assessment. One to two weeks, and it ends with a written document: what your architecture does today, where it will break, what we would change, in what order, and what each phase costs. That document is yours whether or not you hire us for the build. We have handed over assessments to teams who then did the work themselves, and that is a fine outcome.
If we go ahead, the work runs in phases with a fixed price each. Each phase ends with something that runs in production, not a slide deck. We do not open-endedly bill time and materials, because that arrangement rewards us for being slow and we would rather not have that pressure in the room.
We build alongside what you already have. New pipelines run in parallel with the old ones until they are proven. Infrastructure changes go through review and staging first. Cutovers are scheduled, rehearsed, and reversible. Nothing about our work requires you to stop shipping.
What you get at the end
Everything. Repositories, pipelines, Terraform and Helm definitions, dashboards, alert rules, and written runbooks for the operational tasks. Credentials are yours from day one and live in your accounts, not ours.
The test we hold ourselves to is simple: if OpsaFlow disappeared overnight, could your team keep the system running? If the answer is no, the handover is not finished. We have deliberately written ourselves out of systems that would otherwise have been comfortable retainers, because a client who cannot operate their own platform is a client we have failed.
What we will not do
We will not take a project where the honest answer is that you do not need it. If your traffic does not justify Kubernetes, we will say so, and the sentence that follows will cost us the engagement. We would rather have that conversation than spend six months building something you will resent paying for.
We will not promise zero-downtime migrations we have not tested on your data. We will not put a number in a proposal that we have not worked out. And we will not describe a system as "secure" as though that were a finished state rather than an ongoing practice.
Why we build our own products
We run Dioveo, a product of our own with real users, real billing, and real 2am pages. It is not a portfolio piece. It is the reason our advice is worth anything.
Building something and operating it for years are different skills, and the second one teaches you things the first never will. Which alerts are noise. Which clever architecture becomes a liability in month eight. How much of a migration plan survives contact with production data. We would not trust an infrastructure consultant who had never carried a pager, and we do not ask you to.
If any of that sounds like the problem you have, tell us about it. If it does not, we will say so in the reply.