How to run an AI feasibility study in two weeks

A two-week AI feasibility study answers one question: should we build this, and if so, what will it take? Week one is discovery, a data audit and scoring candidate use cases; week two is a thin prototype evaluated on real data, a cost model and a written go/no-go recommendation. Done properly it costs a fraction of a failed pilot and ends with a decision rather than a deck.

TL;DR

• Two weeks is enough to decide, provided the scope is one or two use cases and the right people are available.
• Week 1: interviews, process mapping, data audit, use-case scoring. Week 2: thin prototype on real data, evaluation, cost model, memo.
• The deliverables are an evaluation result, a cost and effort estimate, a risk register and a one-page decision memo.
• The most common failure is testing on clean sample data instead of the messy real thing.

What does a feasibility study need to answer?

Before planning the days, agree what "feasible" means. We frame it as four questions:

1. Is the problem worth solving? What does it cost today in time, money or missed opportunity, and who owns that cost?
2. Do we have the data? Not in theory: can we actually get it, is it labelled or labelable, is it allowed to be used, and is it representative?
3. Can a model do the task well enough? Measured against a threshold the business agrees in advance, on real examples.
4. What will it cost to build, run and maintain, and how does that compare with the value?

If any of these gets a clear "no", the study has done its job. A confident no in two weeks is a good outcome. Our AI consulting engagements are structured around getting to that answer quickly.

Week 1: discovery, data audit and use-case scoring

Day 1: kick-off and problem framing. Meet the sponsor and the people who do the work today. Write the problem statement in one sentence, name the metric that would move, and agree the pass threshold for the prototype. Confirm data access requests are already in motion; waiting for credentials is the most common reason week two slips.

Day 2: process mapping. Sit with operators and walk through the process end to end with real cases. Note where decisions are made, what information is used, where exceptions go and how long each step takes. This is often where the "AI use case" turns out to be a data-quality or workflow problem.

Day 3: data audit. Pull samples from every source the process touches. For each, record volume, freshness, format, ownership, access constraints and obvious quality issues. If a supervised task is in scope, check whether historical decisions can serve as labels, and look for leakage and fields that would not be available at prediction time.

Day 4: use-case scoring. By now there are usually several candidates. Score each on value, data readiness, technical risk, integration effort and change-management burden. Pick one, at most two, to prototype.

Day 5: prototype plan and evaluation set. Define exactly what the thin prototype will do, which model or approach to try first, and how it will be judged. Assemble the evaluation set: a few dozen to a few hundred real cases with agreed correct answers. Have a domain expert review a sample of the labels; disagreements here surface unclear requirements before code is written.

Week 2: thin prototype, evaluation, cost model and memo

Days 6 to 8: build the thin prototype. "Thin" is the operative word: no UI, no integrations, no production infrastructure. A script or notebook that takes real inputs and produces outputs in the format the evaluation needs. For an LLM task that may be a prompt plus a retrieval step over the audited documents; for a predictive task, a baseline model with sensible features. Where retrieval is in play, our RAG systems team will typically stand up a disposable index in a day.

Day 9: evaluate on real data. Run the evaluation set and report the agreed metrics against the agreed threshold. Also report what the numbers hide: failure categories, ambiguous ground truth, and how the errors would land in the real process. Show operators a sample of outputs and record their reactions.

Day 10: cost model and go/no-go memo. Estimate build effort, run cost at expected volume, integration work and ongoing maintenance, and set it against the value quantified on day one. Then write the memo.

What are the deliverables?

The memo should fit on a page and be readable by someone who attended none of the sessions. If the recommendation is "go", it lists the conditions for the build to succeed; if it is "not yet", it says precisely what would change the answer.

Who needs to be in the room?

• An executive sponsor who owns the metric and can make the go/no-go call.
• Operators, the people who do the task today. They validate the process map, label the evaluation set and judge the outputs. Two or three, available for a few hours across the fortnight.
• A data owner with the authority and access to hand over real samples in week one.
• An engineer from the client side who knows where the systems and their APIs live, so the cost model reflects reality.
• The study team: typically an AI lead and one engineer, plus a data scientist if the use case is predictive rather than generative.

Missing any one of these stretches the study; missing the sponsor turns it into a report nobody acts on.

What are the common failure modes?

• Clean sample data. The team receives a curated export, the prototype looks excellent, and production data breaks it. Insist on raw, recent, representative samples.
• No agreed threshold. Without a pass mark set on day one, every result can be argued either way. Agree it before anyone sees a number.
• Scope creep into a pilot. Someone asks for a UI or an integration "since we're here". Decline; those belong in the build.
• Skipping operator review. Metrics can pass while outputs are unusable in practice. Show real people real outputs.
• Ignoring integration and change cost. The model is often the cheapest part. If nobody estimates the integration work and the process changes, the cost model is fiction.

Key takeaways

• Frame feasibility as four questions: is it worth solving, do we have the data, can a model clear the threshold, and what does it cost against the value?
• Week one is discovery, data audit and use-case scoring; week two is a thin prototype on real data, evaluation, cost model and memo.
• Deliver a one-page decision memo with conditions, not a slide deck.
• Get sponsor, operators, data owner and an engineer committed before day one.
• Test on raw, representative data and agree the pass mark in advance.

If you have a use case you would like to put through this process, get in touch and we will scope the two weeks with you.

FAQ

Can a feasibility study really be done in two weeks?

Yes, if the scope is held to one or two use cases and data access is arranged before day one. What takes longer is not the analysis but waiting: for credentials, for a data export, for a stakeholder's diary. Where the data is genuinely inaccessible in that window, we say so on day three and pause the clock rather than proceeding on synthetic samples.

What if the prototype fails the threshold?

That is a successful study. The memo explains why, what would need to change and whether a different approach or a narrower scope would clear the bar. Frequently the answer is a data-quality or process fix that has value on its own. A clear "not yet" for a small fee is far better than the same discovery six months into a build.

Do we need to choose a vendor or model before the study?

No, and it is better not to. The prototype should use whichever mainstream model or method gets to a credible result fastest, because the aim is to test the use case, not the tooling. Model selection, hosting choices and build-versus-buy decisions belong in the memo's conditions and the first weeks of the build, informed by what the evaluation showed.