Builds rarely run into trouble because of the model. They run into trouble because of everything around it: unclear rules, unreachable data, undefined ownership. Almost all of that can be sorted out before the build starts, and doing so is the difference between a smooth engagement and an expensive one.
Write down what happens
Not the documented process. The real one, including the workarounds. Who touches the work, in what order, and what makes them stop and ask someone a question. The questions matter most. Each one is a decision point the system will eventually have to handle or escalate.
Sit with someone while they do the task. You will see steps they would never have thought to mention, because to them it is not a step. It is just how you do it.
Separate the rules from the judgement
Most workflows are a mix of both. “Anything over $5,000 needs a second signature” is a rule. It can be stated, tested and automated reliably. “This customer is usually in a hurry so we push their jobs forward” is judgement, built from context that has never been written down.
Rules are cheap and dependable to automate. Judgement is where AI helps, but also where it needs supervision, clear confidence thresholds and a person in the loop at first. Knowing which parts are which, before the build, shapes the entire architecture.
Find out whether the data is reachable
This is the most common source of delay, and it is entirely knowable in advance. For every system involved, establish:
- Does it have an API, or only a UI and an export button?
- Who controls access, and how long does approval take?
- Are there rate limits that make the intended volume impractical?
- Is the data correct, or does someone quietly clean it up every month?
That last one matters more than people expect. Automation applies the same logic every time and does not intuitively skip records that look wrong. Data a person was silently correcting will surface as exceptions the moment a system starts processing it. Uncomfortable, but better than the errors propagating.
Decide what happens when it is unsure
Every system will meet cases it cannot handle confidently. What it does then is a business decision, not a technical one, and it should be made deliberately.
Does it stop and queue for review? Take the safe default and flag it? Escalate to a named person? Different answers suit different work. The wrong choice for an invoicing system looks nothing like the wrong choice for a scheduling one. Decide before the build, or the decision gets made implicitly by whoever writes that function.
Name an owner
Someone on your side needs to own the workflow after handoff: answering questions during the build, deciding on edge cases, and noticing when something drifts six months later. A system without a named owner degrades quietly. Nobody is responsible for spotting that the exception rate has been climbing since March.
Agree how you will know it worked
Set the measure and capture the baseline before anything changes. Once a new system is running, reconstructing what the old numbers were becomes guesswork, and you lose the ability to demonstrate the improvement to the people who approved the spend.
A week of baseline measurement, taken before the build starts, is the cheapest insurance available on the whole project.