Scoping a Custom Automation Project
How to prepare your firm before a custom build begins, so the first prototype lands right, and what it costs you when it doesn’t.
Most people assume a custom automation project succeeds or fails once the build begins. In practice, the outcome is usually decided earlier than that, in the scoping conversations that happen before a single piece of it is built.
A well scoped project tends to produce a first prototype that already feels close to right. A poorly scoped one tends to produce a first version that reveals, expensively and publicly within the firm, everything that was never actually agreed in the first place. The difference between those two outcomes is rarely the skill of whoever built it. It is almost always the quality of the preparation that happened before they started.
This guide sets out why a custom project is a genuinely different kind of decision to buying an existing tool, what changes inside your firm when you walk in prepared rather than unprepared, and a practical way to get ready before you sit down with a provider, whichever provider that turns out to be.
Why custom is a different kind of decision
When you buy an existing piece of software, the tool itself sets the boundaries of the conversation. You are choosing between features that already exist, and pointing at a screen to say this one, not that one. The tool does a lot of the thinking for you, simply by virtue of already being built.
A custom project has no such boundary to lean on. There is no existing screen to point at. Every question left genuinely unresolved at the scoping stage does not simply disappear. It gets quietly resolved anyway, by someone else’s best assumption, the moment the build actually starts. That assumption then becomes embedded in the system, and unpicking it later is far more expensive than answering the question properly would have been at the start.
In a custom build, every unanswered question does not stay a question. It becomes somebody else’s guess, quietly built into the system, waiting to be discovered later.
What changes when you walk in prepared
The difference between a prepared firm and an unprepared one rarely shows up as a single dramatic moment. It shows up quietly, at every stage of the project, compounding as it goes.
| Stage | Walking in unprepared | Walking in prepared |
|---|---|---|
| Scoping conversations | Broad, general answers, so the provider is left to fill the gaps with assumptions | A specific, real example ready to walk through, so gaps get caught in conversation, while they are still cheap to fix |
| First prototype | Technically works, but misses the real day to day detail, so confidence in the tool drops immediately | Recognisably close to the way the task actually happens, with only minor changes needed |
| Requested changes | Expensive, because they often mean unpicking logic that has already been built around a wrong assumption | Cheap, because they are refinements to something broadly right, not a rebuild of something broadly wrong |
| Timeline | Slips, often more than once, as the real scope gets clarified partway through the build | Predictable, because the scope was genuinely settled before the build ever began |
| Team trust in the tool | Damaged early, as staff quietly conclude it does not understand how we actually work | Preserved, because the first thing people see already reflects their reality reasonably well |
None of this is about which firm has the better provider. Two firms working with the same provider on similar projects can have entirely different experiences, depending entirely on how ready each one was before the scoping conversation even began.
What being prepared actually means
Being prepared is not the same as vaguely knowing what you want. It means arriving with a small number of specific things already worked out.
One real, complete example
Not a tidy, general description of the process, but a single genuine case walked through exactly as it happens today, including the parts that are awkward, inconsistent, or usually handled by exception. This single example does more to prevent a poor first prototype than any amount of general discussion.
A named decision maker
One person, or a small, clearly agreed group, who can actually make a call during the project when a question comes up. Without this, small decisions drift unresolved for weeks, waiting for a meeting that never quite happens.
A clear line between what cannot change and what can
Some systems and requirements are fixed, for good reason, often regulatory. Others are simply how things have always been done and are genuinely open to change. Confusing the two is one of the most common causes of a scope that quietly grows out of control.
Confirmed access to the systems involved
Access requests inside larger firms can take longer than the scoping conversation itself. Checking this in advance, rather than discovering it mid project, protects the timeline more than almost anything else on this list.
A working definition of done
A specific, checkable description of what the first prototype needs to demonstrate to be considered a success, agreed before work begins, not reconstructed from memory once it arrives.
A simple process to get ready before you scope anything
- Write down one real case, start to finish. Include exactly where it usually goes wrong, gets complicated, or needs an exception. The messy parts matter more than the tidy ones.
- Name your decision maker before the first conversation. Agree who can actually say yes or no during the project, rather than discovering the gap the first time a decision stalls.
- List what cannot change, separately from what can. Be explicit about which constraints are genuinely fixed, so nobody wastes time designing around a limit that was never actually real.
- Confirm access to every system involved, ahead of time. Raise any internal access requests early, well before the scoping conversation, so the project is never waiting on a form.
- Agree what a successful first prototype will actually demonstrate. Put it in writing, specific enough that everyone in the room would recognise success the moment they saw it.
- Bring the exceptions, not just the happy path. Raise the awkward cases in the very first conversation. They are usually where the real complexity, and the real cost, was always hiding.
The mistakes that undo good scoping anyway
Treating scoping as a formality
The instinct to get through the scoping conversation quickly so the real work can begin is understandable, and usually backfires. The scoping conversation is the real work. Everything after it is simply carrying out what was decided there.
Letting different people describe the process differently
It is common for two people in the same firm to describe the same task in genuinely different ways. If that conflict is not resolved before the build starts, the provider has to guess which version is correct, and may not guess the one you would have chosen.
Assuming the detail is obvious
A provider who works across many firms will not automatically know the specific way your firm handles a particular situation, however standard it feels from the inside. If it matters, it needs to be said, not assumed.
Leaving out the exceptions because they feel like a small detail
The parts of a process that happen only occasionally are often exactly the parts that take the most thought to automate properly. Leaving them out of the scoping conversation does not remove the complexity. It just delays the moment you discover it.
Reviewing the first prototype against a fading memory
Without a specific example and a written definition of success to check against, a prototype review can turn into a debate about what was actually agreed weeks earlier, rather than an honest assessment of the work itself.
What a well scoped project actually feels like
Firms who prepare properly tend to describe the same experience. The first prototype review feels like a moment of recognition rather than a surprise. The changes requested are small and specific, refinements rather than a rethink. The team trusts the tool from the start, because what they are shown clearly reflects the way they actually work, not a general idea of it.
The time spent preparing properly before the scoping conversation almost always turns out to be the fastest route through the whole project, not a delay to it. Firms who skip that preparation do not save the time. They simply spend it later, at a point in the project where it costs considerably more.
That preparation is entirely within your control, well before any provider, including us, is ever in the room.
