THEMost software buying starts with a catalogue. A team lists features, compares products and chooses the closest fit. That is reasonable when the work is standard and the cost of adaptation is low. Complex operations are different.
In a complex operation, the important details live between the boxes on the process diagram. They sit in handovers, exception paths, specialist judgment, regulatory obligations, ageing infrastructure, fragmented data and the practical limits of what people can do during a busy shift. Those details are not peripheral. They are the system.
The operation is the primary design input
Good operational software begins with observation and mapping. Who makes which decision? What information is available at that moment? Which system is authoritative? What happens when the information is incomplete? Where does approval sit? What must remain traceable six months later?
This work produces something more useful than a list of requested features: a model of the operation. That model gives engineering teams a way to distinguish what is essential from what is merely familiar.
A workflow is not a sequence of screens. It is a chain of responsibilities, information and decisions.
Configuration has a boundary
Off-the-shelf products are valuable when their underlying assumptions match the organisation. Configuration can cover terminology, permissions, fields and a degree of workflow variation. But every product contains an opinion about how work should happen. Once the real operation moves beyond that opinion, “configuration” starts to mean parallel spreadsheets, manual reconciliation and people becoming the integration layer.
That is the point at which custom engineering becomes less about novelty and more about removing accumulated operational friction. The goal is not custom software for its own sake. The goal is a system whose boundaries, data model and interfaces reflect the job.
Design for the exceptions first
Happy paths are easy to demonstrate. Operational confidence is earned in the exceptions: the missing reading, the delayed approval, the conflicting record, the offline site, the unusual case that requires a specialist. If the system cannot show what happened, preserve context and let a person intervene safely, it has not been designed for real use.
This is also where AI must be handled with care. A model may help classify, retrieve or recommend, but responsibility does not disappear. The surrounding software still needs permissions, evaluation, provenance, fallbacks and clear escalation.
Can the system explain the state of the operation?
Not just what the model predicted or which button was pressed, but what information was used, which rule applied, who acted and what needs attention next.
Build the smallest coherent capability
Starting with the operation does not mean attempting a multi-year replacement programme. It usually points toward a smaller, more coherent first release: one workflow, one painful handover, one decision that can be materially improved.
The first release should prove the hard assumptions and connect to the systems that matter. It should be observable enough to learn from. It should leave the organisation with a clearer foundation, not another isolated tool.
Software should earn its place
The best operational software can feel unremarkable after adoption. It fits the language of the work. It brings the right information together. It reduces ambiguity without hiding complexity. People spend less time serving the system and more time doing the job the system exists to support.
That is the standard behind “built for the operation.” It is not a preference for bespoke interfaces. It is a commitment to make the technology answer to the real environment in which it must perform.