Software That Solves Real Business Problems at Scale

There is a point in the growth of most operations heavy businesses where the tools they use stop being adequate. The spreadsheets have too many tabs. The packaged software has a workflow that is close to what you need, but not close enough, and the workarounds have accumulated to the point where nobody is sure what the correct process actually is.

At that point, one of two things happens. The business commissions bespoke software and gets something that genuinely solves the problem. Or it commissions bespoke software and gets something that creates a different set of problems: expensive to maintain, difficult to extend, and so tightly tied to how people worked at the time it was built that it becomes an obstacle as the business evolves.

The difference between those two outcomes is almost never the technology chosen. It is the quality of the thinking that went into understanding the problem before a line of code was written.

Why packaged software stops working

Packaged software is built for the average case. It handles the processes that most businesses of a given type share: invoicing, scheduling, HR records, reporting. For those shared processes, it is usually good enough and often cheaper than building.

Packaged software stops working when your operational reality diverges from the average case far enough that the software's assumptions become constraints. When your workforce scheduling involves rules that the system cannot represent. When your compliance reporting requires data relationships the tool was not designed to track. When you need five systems to talk to each other and the integration options are limited or expensive. When the thing you actually need to do sits in the gap between what two tools each handle.

The accumulation of workarounds is often the signal that this point has been reached. When staff have a documented procedure for how to use the software that involves steps the software does not support, such as manual exports, re entry in another tool, or paper records kept alongside the digital ones, the software is not solving the problem. It is participating in the problem.

Custom software is not always the answer to this. Sometimes a configuration change unlocks what you need. Sometimes a different packaged product is a better fit. But when neither of those options exists, custom software built against your actual processes is the right move, and it needs to be built properly.

Operational complexity is always underestimated

There is a pattern that repeats across almost every operational software project: the problem looks simpler than it is until you sit with the people doing the work.

A shift management system sounds straightforward. Until you discover that the scheduling rules depend on staff certifications that expire at different times, that some roles require two qualified people to be present simultaneously, that the definition of a "shift" varies by department, and that the system needs to produce reports that match a regulatory format different from the one your HR team uses internally.

None of these are unusual requirements. They are the kind of operational detail that exists in every sufficiently complex business and that cannot be discovered from a requirements document. It only comes from extended, specific conversation with the people who run the operation day to day.

The consequence of underestimating this complexity is software that handles the obvious cases and breaks on the real ones. It works in testing. It fails in the first week of production when someone tries to do something the developer did not know was possible.

Good operational software is built on thorough discovery, not assumption. The discovery work, understanding existing processes in enough detail to design around them, is not overhead. It is the part that determines whether the software will actually be used.

Systems that fight workflows against systems that fit them

Software that sits alongside how people work gets used. Software that requires people to work around it gets abandoned or worked around. The distinction sounds obvious, but it is routinely missed in custom software projects.

The failure mode is designing a system that reflects what the process should be, rather than what it is. The system is built on a process diagram approved in a meeting. In practice, the process has exceptions, informal steps, and contextual judgements that did not make it onto the diagram. The system does not accommodate those, so people route around it.

Designing for how work actually happens requires spending time with the people doing the work as well as their managers. It requires watching how decisions get made as well as reading the policy. It requires understanding where the current tools succeed well enough that people will not want to change, and where they fail badly enough that people will welcome the replacement.

The result of this kind of discovery is software that users reach for rather than avoid. That is the fundamental measure of whether operational software has worked.

The hidden cost of staying with spreadsheets

The business case for custom software is often framed against the cost of building it. It is less often framed against the cost of not building it.

Manual processes have costs that accumulate quietly. Time spent on data entry that could be automated. Errors that stem from re keying information between systems. Decisions made on data that is a day old because the reporting cycle takes that long to run. Compliance risks that sit in uncontrolled spreadsheets. Operational capacity limits that are process limits in disguise. The business cannot take on more volume because the process does not scale, not because the market is not there.

These costs are real and material. They are just harder to put in a spreadsheet than the cost of a software project. When the analysis is done properly, the business case for building is usually stronger than it looks from the cost side alone.

The Hidden Cost of Manual Processes in Operations Heavy Businesses →

Build versus buy for operational software

Build versus buy is not a single decision. It is a decision made at the level of each functional area, and the answer is different in each case.

The general principle: buy what is commodity and generic; build what is differentiated and specific. Standard financial reconciliation processes are a candidate for packaged software, because they are well understood and the software is mature. The specific operational logic that makes your workforce management work the way it does, the one that took years to refine and is embedded in the institutional knowledge of three people, is not a candidate for packaged software because no packaged product was built for your specific version of the problem.

HR and compliance software is a good example of where this decision has real consequences. The basic record keeping, including employee records, absence tracking, and holiday entitlements, is almost always better bought than built. The specific contract templates, approval workflows, and reporting requirements for your industry or company structure may not be well served by any available product. Understanding which parts of the problem are commodity and which are specific to your operation is the work that makes the build versus buy decision sensible rather than arbitrary.

HR and Compliance Software for Growing Teams: What to Build vs Buy →

Legacy integration: the constraint that shapes everything

Almost every operational software project has a legacy integration requirement. An existing system that holds ten years of customer records. A finance platform that cannot be replaced. An external system that a key partner relies on. These integrations shape what is possible and determine much of the risk.

Legacy integration is often the most technically complex part of an operational software project, and it is underestimated in almost every project plan. The existing system's API is underdocumented. The data model has evolved over years in ways that were not recorded. The behaviour under edge cases was not specified because nobody expected any other system to interact with it at this level of detail.

The practical approach is to treat legacy integration as a core concern from the start, not a late task. Understanding the integration surface early determines the data model, the synchronisation strategy, the error handling, and the rollback options if something goes wrong. Discovering these constraints late typically means expensive rework.

System Integration for Legacy Environments: A Practical Approach →

Multi tenant platforms: decisions that age badly

If the software you are building will serve multiple clients, business units, or customer groups, each with their own data, their own configuration, and some expectation of data isolation, the architecture decisions made early have a very long tail.

A multi tenant platform built with shared database tables and tenant IDs filtering every query is viable at small scale and increasingly painful as the number of tenants grows. A row level security model that works for ten clients may not perform adequately for a thousand. A configuration system designed around boolean flags struggles when clients need fundamentally different behaviour, not simple toggles.

We built a rewards platform serving multiple tenants, including UK government departments, major accounting firms, and enterprise businesses, all from the same infrastructure. The decisions made in the first year determined what was and was not possible in year ten. Getting the architecture right at that stage, before the accumulated weight of clients and data makes change expensive, is one of the highest return engineering investments you can make.

Long-term evolution: designing for change

Businesses change. Regulations change. The operational problems that feel most pressing today will not be the same ones that matter in three years. Software that was built as a snapshot of the current state, without any design for extensibility, will become a constraint on the business rather than an enabler of it.

The alternative is software designed with clear boundaries between its components, where a change to one part does not require changes to everything that depends on it, where new requirements can be accommodated without rewrites of existing functionality, and where the data model can evolve without breaking existing consumers.

This is not architectural theory. It is the practical difference between a system that a team can add new capabilities to in weeks and a system where every change is a risk assessment. Operational software that works well in year one and is still serving the business effectively in year seven is the outcome we design toward, because that is the measure of whether it actually solved the problem.

From Spreadsheet to System: When Your Business Has Outgrown Excel →