A production system is not a model with some engineering around it. It is a large, layered system that happens, sometimes, to contain a model. The pipelines, the protocols, the drivers, the firmware, the signal chain, and the seams between them are the rest, and they are where serious programs are won or lost.
That has a structural consequence most firms are not built for. If the risk concentrates in the boundaries, then a firm that owns one layer cannot own the risk, however good it is at that layer. It can only do excellent work up to the edge of its scope and hand the problem across.
So the firm is built the other way around. One principal with genuine depth from the baseboard controller to the model, accountable for the program rather than for a slice of it. The range is not there to be impressive. It is there so the seams have an owner.
Why an organization ends up with the wrong help.
Everyone else hands the problem across the seam. We are the one who does not. When an organization has a hard, cross-layer production problem, it weighs four options, and each is structurally wrong for it.
One owner, from the baseboard controller to the model.
A principal with genuine depth from the baseboard controller to the model, who owns the whole problem and is accountable for the outcome. No large-firm overhead, no hand-off at the boundary.
Mostafa Dhouib
The range, in the present tense.
Right now, Mostafa is architecting and leading across three of the hardest domains in engineering at the same time: production infrastructure at fleet scale, a biometric wearable from the sensor up, and edge autonomy for uncrewed defense platforms, while serving as CTO of a defense-tech startup building tactical uncrewed systems.
Three programs, three of the hardest domains there are, carried at once. That is the evidence for everything else on this site. Over a decade behind it: 40+ shipped systems across 9+ verticals, from defense and uncrewed platforms to medical devices, industrial automation, robotics, and infrastructure at scale.
Writing code since thirteen. Dropped out in the second year of college when a client delivery landed that could not afford to fail, chose the system over the lecture hall, and never went back.
The range is deliberate and it is unusual: the same person owns the Redfish call to the baseboard controller and the quantization decision on the edge module, and has shipped both.
There is a reputation that comes with this kind of range, and it is only half the story. Mostafa is the person called when a system works on the bench, falls apart in the field, and the last two engineers could not say why.
A production model tested at 95% in staging. A week after launch it was sitting at 44%. Two experienced contractors reviewed it independently and both recommended a multi-month rebuild of the model. The cause was in the data, not the model: the training set had been recorded almost entirely by one person, so the model had learned that person rather than the task, and it collapsed the first time it met real users. The fix took five days.
That skill is real and it is why clients trust the judgment. But being good at finding a failure is not the same as being the firm you call once there is one. Diagnosis is one of five ways in, and the least valuable, because by the time it is needed the expensive decisions are already made. The work that matters most happens earlier, on programs that have not failed and are not going to.
Five principles. We do not bend them to win an engagement.
Founder-led, deliberately small, principal inside every system.
Opulion takes a few select clients at a time. The principal designs your system, leads its delivery, and is accountable for the result. That is the opposite of the big-firm model, where the people who sold the engagement never touch it.
Smallness is a quality choice, not a capacity ceiling. Programs are delivered by principal-led teams, staffed to the work, with the architecture and the critical path owned by the person whose name is on the outcome. The firm is deliberately small so that the person who decides your system is the person who builds it, not so that a program depends on any single day of anyone's availability.
What we do not do is supply hands to a plan somebody else is responsible for. If the work is a staffing gap rather than an ownership gap, we are the wrong firm and will say so early, which is cheaper for both of us than finding out at the first milestone.
Contract, fractional, or advisory.
We price against milestones and outcomes, not hours on a clock. The engagement is priced against the six-month rebuild of the wrong thing that it prevents, because the most expensive line item in a mission-critical program is the architecture decision nobody caught.
We optimize for being right.
We would rather lose an engagement than take one we are wrong for. We are not optimizing for the size of the contract. On programs where failure is expensive, being right is the only thing worth being, and everything about how the firm is built, deliberately small, principal-led, priced against the rebuild it prevents, follows from that one commitment.