AI research & feasibility
Is the idea worth building?
An AI feasibility study helps you decide whether a specific task deserves a prototype, what it must test and what could prevent it working.
Discuss your question
Start with the uncertainty that matters.
A team wants to search its internal procedures with AI. Before choosing a model, someone needs to establish whether the documents are current, whether access can be controlled and whether the questions have answers in those documents at all.
That is the purpose of a feasibility study. We examine a defined use case, the available material and practical constraints, then recommend a proportionate next step. It suits product owners, technical teams and domain specialists deciding where to invest.
If the question and data are already clear, a proof of concept may be the better starting point. If a system already exists, consider model evaluation.
The investigation
Understand the task before selecting the tool.
Frame the decision
Define the intended user, acceptable output, consequences of error and the investment decision the study must inform.
Examine permitted material
Review representative examples, missing information, document versions and access constraints. Explain where a sample cannot represent future use.
Compare possible approaches
Consider ordinary search, rules or process changes alongside model-based methods. Identify the assumption whose failure would change the decision.
Recommend the next step
Proceed with a focused experiment, resolve a data problem, narrow the task or stop. Record why and what evidence could change the recommendation.
What you receive.
- A task and decision brief with explicit boundaries.
- A data-readiness assessment based on the material examined.
- A comparison of plausible approaches and simpler alternatives.
- A record of assumptions, dependencies and unresolved risks.
- A proposed experiment with acceptance and stop criteria.
- A recommendation discussed with your decision owner.
An example of a useful conclusion
For an internal procedure assistant, a study might recommend testing source retrieval first because documents conflict or important answers are missing. It might recommend fixing the source collection before generating answers. This is an illustrative outcome, not a reported client result.
How you judge the work
The recommendation should answer the original decision, trace its reasoning to the material examined and make the remaining uncertainty explicit. A positive recommendation is not the only successful outcome.
Use our feasibility study guide to prepare an initial brief.
Before we start
A scope you can make a decision on.
Scope, fee and timing
The cost depends on the number of tasks, source systems, data preparation, specialist reviews and depth of technical investigation. Starting with one decision and one permitted sample keeps the scope easier to assess.
We agree the question, deliverables, exclusions, fee and review dates in writing before work begins. Data access and reviewer availability affect the schedule. If the question changes, we agree the change before extending the work.
What we need from you
A decision owner, examples of the intended task, permitted source material and a domain contact who can explain what a useful answer looks like. An early idea is enough for the initial conversation.
Handover and the next stage
The handover includes the agreed report, methods and shareable project artefacts. Ownership, third-party licences and data permissions are settled in the engagement terms. Production implementation, hosting and ongoing support are separate decisions; the findings can go to your own engineers or an implementation partner.
Do we need a technical specification?
No. Describe the decision, intended users and a few examples of the work. Defining a useful technical question is part of the study.
Will you recommend against using AI?
Yes, where the evidence supports that conclusion. A simpler process, search tool or rule may be the appropriate answer.
How long does a study take?
Timing is agreed after reviewing the question, data access and required specialist input. The proposal identifies review dates and dependencies rather than promising a universal duration.
Does feasibility include a production build?
No. It produces evidence and a proposed next step. A prototype or production implementation is separately scoped.