Home/MU·01/Custom software engineering
MU·01 Technology
Full-lifecycle build for operating businesses: discovery with the people who will actually use the thing, architecture, delivery, and the long tail of running it in production. We do not hand over a repository and leave.
Generic enterprise software assumes an office — steady connectivity, a nine-to-five calendar, a user at a desk. Heavy industry runs on a rig, a blending line, a warehouse floor or a crew boat, where connectivity is intermittent, shifts rotate through the night, and the record of what is true has to survive a handover between people who never meet.
That environment changes engineering decisions rather than just interface design. Offline behaviour becomes a correctness question, not a nicety. Time is modelled as rotations rather than dates. Identity has to account for a contractor who is on board this week and gone the next.
Most work starts as a diagnostic: we map where the record actually lives today, who re-keys it, and what breaks at handover. That normally produces a smaller first build than a client expects, because the first release is aimed at the single reconciliation costing the most money — not at a feature list agreed in advance.
From there the rollout is incremental and the old process keeps running alongside until it is redundant. We then operate what we built: uptime, security posture, patch and release cadence, held to contract rather than to best effort.
The group runs five operating businesses of its own, which shapes how this arm works. We are accustomed to owning the consequences of software long after the invoice, because internally we always have. A system that is difficult to run is not finished, whatever the acceptance criteria said.
This is also why we decline work we cannot support. The same operating rule the group applies to acquisitions — never own something you cannot run yourself — applies to what we agree to build.
Where we rank options — a routing, a supplier, a schedule — the interface has to state why the top result won, in terms an administrator can dispute. A score with no argument behind it is not a decision aid; it is an unaccountable instruction. We build recommendation systems that show their reasoning, and we do not put generative output into a record that has to be signed.
What this covers
Questions
Yes. The pattern we are good at — collapsing a fragmented operational record into one auditable system — is not specific to offshore. It applies wherever shift work, certification and contract reconciliation meet.
Rarely as a first engagement. A diagnostic usually changes the scope enough that a fixed price agreed beforehand would be wrong for both sides.
Where we build a bespoke system, the client normally owns it, and we will hand it over. We would rather keep operating it, but ownership is not the lever we use to stay.
Chosen per engagement against what the client can maintain, not against what is currently fashionable. A stack nobody at the client can run is a liability we have handed them.
A diagnostic is the smallest useful unit of work. It is deliberately cheap relative to a build, because its job is to establish whether a build is warranted at all.
Continue
We map the record before we propose a build.