Enterprise software is often designed around a tidy version of work. An order moves from one status to another, an inspection follows a fixed sequence and an asset has one owner and one location. Real operations are less cooperative.
A returnable container arrives without a readable identifier. A quality hold interrupts production. A warehouse loses connectivity. A supervisor needs to approve an exception between shifts. These details can look minor during a boardroom workshop, but they decide whether a system becomes part of the operation or another screen users work around.
This is the case for domain-led software development: pairing strong engineering with people who understand the physical process, terminology, constraints and consequences. It is not an argument that every business should build everything from scratch.
The Missing Role Is Often an Operational Translator
Developers need precise decisions. Operators describe work through experience, local language and exceptions. Managers focus on targets, risk and reporting. An operational translator connects those views without flattening them into a generic requirements document.
That person might be a product owner, process engineer, quality specialist, supply-chain lead or technical consultant. The title matters less than the capability to:
- observe the real workflow rather than only the documented procedure;
- separate essential controls from historical habits;
- explain operational consequences to engineers;
- turn technical constraints into understandable business choices;
- make timely scope decisions; and
- judge whether a prototype works under realistic conditions.
The UK Government Service Manual advises teams to research current behaviour and involve people who deliver and support a service before planning and building it. That principle applies just as strongly to a plant floor, warehouse or quality laboratory.
Why Generic Requirements Miss Operational Reality
The process has more exceptions than the diagram
Most process maps show the expected path. Useful software also needs to handle rework, damaged stock, quarantine, missing identifiers, rejected approvals, partial returns and competing sources of truth. If those cases are discovered after configuration, the team either adds awkward workarounds or expands the project.
The interface is part of the operating environment
A desktop form that works in a quiet office may fail on a shared tablet, in poor light, while the user wears gloves or when each extra field delays a production task. Domain knowledge helps teams choose what must be captured at the point of work and what can be derived automatically.
Every extra step has a cost
Enterprise systems frequently optimise for completeness rather than flow. A field may be valuable to reporting but difficult for an operator to know reliably. Forcing an answer does not create good data; it can create invented values, shared logins or activity outside the system.
Research on ERP implementation repeatedly identifies user involvement and system fit as important. A 2023 systematic review found user participation among the leading concerns in ERP research, while another review of critical failure factors highlighted mismatch with business strategy, inadequate training and unwillingness to use the system.
Build, Buy or Extend?
Domain-led delivery should improve the decision, not predetermine it. There are three broad routes.
Buy when the process is genuinely standard
Payroll, basic accounting, identity management and many common administrative processes benefit from mature products. Buying is usually sensible when the workflow is not a competitive advantage, regulation is well understood and the organisation can adopt the product’s operating model without harmful compromise.
Customising a standard process can create unnecessary cost and long-term maintenance. The difficult but valuable question is whether the business is protecting a real operational requirement or simply preserving an old preference.
Extend when the core platform works but an operational gap remains
An ERP may remain the right system of record while offering a poor experience for a specific frontline task. A focused mobile workflow, API, scanner process, inspection tool or exception dashboard can close that gap without replacing the core platform.
This route is particularly useful when the business needs faster feedback or when a full ERP change would expose too many dependencies. It still requires proper integration, security, ownership and support; an extension should not become an invisible second ERP.
Build when the workflow is distinctive and valuable
Custom software makes sense when the process materially differentiates the operation, available products cannot support critical constraints, or repeated manual work and losses justify ownership of a tailored capability.
The business should be able to state the advantage in operational terms: fewer lost assets, faster release from quality hold, shorter inspection time, better traceability or a lower error rate. “Our process is unique” is not enough on its own.
Why Smaller Operational Releases Reduce Risk
A domain expert can shorten discovery because they recognise terminology and common failure modes. They cannot responsibly remove validation. The speed comes from testing a narrower solution with the right people, not from assuming the first idea is correct.
DORA describes customer feedback, small batches and team experimentation as connected capabilities that predict software-delivery and organisational performance. For operational software, the “customer” includes the person scanning, inspecting, approving or resolving exceptions every day.
A useful rapid cycle might look like this:
- Observe one workflow. Record the normal path, exceptions, constraints and baseline performance.
- Choose one measurable outcome. Avoid a broad promise to “digitise operations”.
- Prototype the risky interaction or integration. Test it with representative users and realistic data.
- Build one production-grade slice. Include identity, permissions, logging, monitoring and support.
- Run it alongside controlled operations. Capture errors, bypasses and user feedback.
- Expand only when the evidence supports it. Keep, change or stop based on results.
This avoids the delay pattern described in Why Enterprise Software Projects Take So Long and Still Miss the Mark: broad scope, late feedback and expensive correction.
Domain Expertise Does Not Remove Engineering Discipline
Operational familiarity can become a risk when one expert’s experience is treated as universal. A robust team still needs user research across roles and shifts, secure architecture, automated testing, accessibility, data governance and clear technical ownership.
Documentation also matters. Google Cloud’s DORA research found that teams with higher-quality documentation were more likely to achieve stronger software-delivery and operational performance. Fast delivery that depends on one person’s memory is not a sustainable enterprise solution.
The strongest model combines three forms of knowledge:
- Operational knowledge explains the work, risks and exceptions.
- Product and user-research knowledge tests whether the proposed change helps representative users.
- Engineering knowledge makes the solution secure, maintainable, observable and compatible with the wider technology estate.
Questions to Ask a Delivery Partner
- Who will observe the process where the work happens?
- How will frontline users influence scope before development?
- Which assumption will be tested first?
- What useful outcome can be released independently?
- How will the solution handle exceptions, outages and poor data?
- What stays in the ERP or existing platform?
- How will security, audit, monitoring and support work?
- Which measures will prove that the operation improved?
- Who owns the code, documentation and future changes?
Conclusion
The best enterprise software is not defined by how much code is custom. It is defined by how well the technology supports the work, controls risk and creates measurable value.
Domain-led development helps because it brings operational consequences into technical decisions early. Sometimes that leads to a bespoke tool. Sometimes it leads to a small extension, a configuration change or the decision not to build at all. That is the real advantage: not custom software for its own sake, but a faster path to the smallest solution that genuinely works.