Most systems are built to ship.
These are built for clients who cannot afford failure
Software & Security is the oldest line of the practice: its records on this domain date from 2011. The work is custom systems built to order, integrations fitted into environments that already exist, and security review of what a client already runs. The same line tools the house itself. The firm's complete electronic-signature infrastructure was built in-house, end to end; the cognitive frameworks the practice runs on were built here; the instruments the Mulium Special Unit carries into an investigation were built here. Nothing the firm depends on is rented. A client engaging this line gets the discipline the firm applies to its own work, not a methodology bought in for the occasion. Every other line of the practice runs on what this one builds.
01Build what you depend on
A tool you rent is a dependency, and a dependency is a risk with a billing address. Terms change, prices change, access is revoked, products are retired, and the work that stood on them stops standing. For systems a client merely uses, that risk may be acceptable. For systems a client depends on, it rarely is. The line builds the instruments that carry real weight: the ones that hold the record, move the value, or sign the commitment. Owning the instrument means owning its behaviour, its data and its future, and answering for all three. The firm holds itself to the same rule, which is why its own signing infrastructure was built in-house rather than bought.
02Integration without exposure
Most new software enters an organisation by widening its attack surface: another credential, another connection, another party with standing access to internal data. The line treats integration as a security exercise first and a plumbing exercise second. A new system is fitted into the client's environment along the narrowest path that does the job, with access granted by need rather than by convenience, and with every connection documented so it can be examined, narrowed or severed later. What a system does not need to see, it is not shown. The measure of a good integration is not how much it connects. It is how little of the client it exposes while connecting.
03Review before the incident
A security review is a reading exercise. Tools enumerate what a system contains; a reviewer reads what it will do under pressure, and where the gap sits between what was intended and what was built. Systems fail at boundaries, at assumptions nobody wrote down, along paths nobody believed reachable, and through privilege that accumulated quietly over years. The review reads for those points before someone hostile does, and writes them down for the person who has to fix them: dated, reproducible, ranked by consequence rather than by count. The review that matters is the one done before the incident. Afterwards, the same reading is done anyway, on someone else's terms.
If your organisation depends on a system it does not control, or runs one that nobody has read closely in years, state the matter in writing; it is reviewed individually, and answered either way.