Building Software Around Operations, Not Assumptions

Effective software begins with understanding how an organisation actually works — not with a list of features or a preferred technology stack.

Too many systems fail because they were designed around assumptions: assumptions about how processes work, what users need, or how information flows between teams. When those assumptions are wrong, the result is software that looks complete but creates friction in daily use.

Start with the operation

Before defining interfaces or selecting technologies, we map the real operation:

• How do people currently complete their work, step by step?
• Where does information originate, who touches it, and where does it need to arrive?
• What are the exceptions, workarounds and informal processes that the formal documentation misses?
• Who are the actual users, and what do they need to accomplish?

This discovery phase often reveals that the proposed solution is not the right one — or that a smaller, more focused system would deliver greater value than a larger platform.

From operation to architecture

Once the operation is understood, architecture follows naturally. Data models reflect real entities and relationships. Workflows mirror how work actually moves. Integrations connect systems that already exist rather than requiring wholesale replacement.

The result is software that fits the organisation, rather than forcing the organisation to fit the software.

A practical test

Before committing to a design, ask: could a new team member understand why this system works the way it does by observing the operation it supports? If the answer is yes, the architecture is likely well-grounded. If not, there may be assumptions worth revisiting.