How I scope a custom AI project in the first 30 minutes
A transparent look at the questions I ask and the signals I look for before recommending anything, and why the scoping conversation is often more valuable than the build.
How I scope a custom AI project in the first 30 minutes
When someone books a call with me, they usually come with a solution already in mind.
"We need a chatbot." "We want to use AI to process our documents." "Can you build us something like ChatGPT but for our data?"
I dont start there. I start earlier.
The first thirty minutes of any engagement are not about the technology. They are about understanding the workflow that is broken, what it is costing, and whether building something custom is actually the right answer. Sometimes it is not. Better to find that out on a call than six weeks into a project.
Here is what I am actually trying to figure out.
What is the workflow right now?
The first thing I want to understand is what the process looks like today, step by step.
Not at a high level. In detail. Who does it? When does it happen? What do they start with, and what do they produce at the end? How long does it take? What do they do when something doesnt fit the normal pattern?
Most people have not mapped this out explicitly. The process lives in their head or in the heads of two or three people who do it every day. Part of the value of the scoping conversation is that mapping it out surfaces things that werent visible before: the edge cases that take disproportionate time, the steps that exist only because the previous system required them, the approvals that nobody remembers why they added.
I am looking for the specific part of the workflow that is genuinely painful. Not everything. Just the bottleneck.
What does it cost?
Once I understand the workflow, I ask about volume and time.
How many times does this happen per day, or per week? How long does it take each time? How many people are involved?
Then I do the arithmetic out loud. If ten people are spending two hours each on this task every week, that is a hundred hours of staff time per week. At a fully-loaded cost of sixty pounds an hour, that is six thousand pounds a week, three hundred thousand a year.
That number is almost always larger than people expect. Because the cost is distributed, it is invisible. Nobody sees it as a line item. It just exists as slowness, backlog, and the sense that the team is always behind.
Understanding the cost does two things. It tells me whether a custom build is worth the investment. And it gives the client a concrete frame for evaluating the return, which they will need when they make the case internally.
Is the input structured or unstructured?
This is the question that most quickly tells me what kind of solution we are dealing with.
If the inputs are structured, consistent forms, clean data, predictable fields, the solution is usually a rules-based automation or a simple integration. No AI required. Fast to build, easy to maintain.
If the inputs are unstructured, documents that vary in format, requests that arrive in natural language, records that need interpretation rather than just extraction, that is where AI earns its place. The value of a language model is specifically in handling variability that rules cannot.
The answer is often somewhere in between. A document processing workflow might have structured metadata and unstructured content. Knowing which parts are which tells me where to apply AI and where not to.
What does good look like?
I ask this directly: if we built the perfect version of this, what would change?
The answer tells me what the real success criteria are. Sometimes it is speed, a process that takes two days should take two hours. Sometimes it is accuracy, too many errors are slipping through the manual review. Sometimes it is consistency, different people are doing the same task differently and the outputs vary.
Each of those implies a different solution design. A speed problem is usually about automation and parallelisation. An accuracy problem might require a confidence-scoring layer with human review for low-confidence cases. A consistency problem is often about encoding the decision rules that currently exist only in people's heads.
If I build something optimised for speed when the real problem is consistency, it will not feel like a success even if it is technically fast.
What data exists and where does it live?
Almost every AI project depends on data that the organisation already has. Documents, records, transaction history, case notes, emails.
I want to know: what exists, where it is stored, how it is organised, and how accessible it is. A well-organised SharePoint library and a folder structure that nobody has touched in four years are very different starting points.
I also want to know about quality. Data that is inconsistently formatted, partially complete, or spread across three systems that dont talk to each other adds friction to any build. Not insurmountable, but it changes the scope and timeline significantly.
The organisations that move fastest are the ones that have their data in one place and can give me access to it. The ones that move slowest are the ones where getting the data out of the legacy system turns into a project of its own.
Who owns it after I build it?
This is the question that gets skipped most often and causes the most problems later.
Custom software requires ownership. Someone needs to monitor it, update it when the underlying workflow changes, manage the integrations when the connected systems update, and make decisions about how it evolves over time.
If there is nobody in the organisation who can do that, or nobody willing to, then I am either building something that will be abandoned, or I am being hired indefinitely to maintain it. Neither is ideal.
I am not looking for a team of engineers. I am looking for one person who understands the workflow, cares about the outcome, and can be the internal champion for the system. That person exists in most organisations. Finding out whether they are available and engaged is part of scoping.
The output of the conversation
By the end of thirty minutes, I usually know:
- Whether the problem is real and significant enough to justify a build
- Whether AI is the right approach or whether simpler automation would do the job
- What the core system needs to do and what it explicitly does not need to do
- What the data situation looks like and whether it is a blocker
- Whether the organisation is set up to get value from what I build
If the answers are good, I will come back with a scoped proposal: a clear description of what I will build, what I will not build, what I need from the client, a timeline, and a cost.
If the answers are not good, if the problem is too small, the data is too messy, or there is no internal owner, I say so. It is not the answer anyone wants in the moment, but it is more useful than six weeks of work that does not land.
The honest bottom line
The scoping conversation is not a sales call. It is a diagnostic.
My job is to figure out whether there is a real problem, whether I can solve it, and whether solving it is worth the investment. If all three are true, we move forward. If any of them are not, I will tell you. The alternative is building something that does not get used, and that serves nobody.
If you have a workflow that is costing your team significant time and you are not sure whether it is a good candidate for AI, the thirty minutes is worth it just to find out.