AI feasibility study

Whether AI is the right tool here, before anyone builds anything.

Which class of approach fits, what data it needs, what it costs to run once it is live. Including the version where the honest answer is no.

What this is

A feasibility study is a short, bounded piece of work that answers four questions before a single line of production code gets written: does AI apply to this problem at all, which class of approach fits it, what data does it actually need and do you have it in a usable form, and what does running it cost, in money and in latency, once it is live rather than in a demo. The deliverable is a written report and, where it is the fastest way to answer the open question, a small prototype against real data.

This exists because of a specific failure mode. Teams that skip it build the thing they assumed was needed and find out nine months in that the documents they meant to search were never digitized, or that the accuracy a regulated process needs is a research problem rather than an engineering one, or that per-query cost at their actual volume makes the whole approach uneconomical. All three are cheap to find out in a few weeks and expensive to find out after a build.

Sometimes the answer is that a regex and a lookup table solve the problem better than a model, because the input format is genuinely fixed and the volume does not justify probabilistic tooling. Sometimes the answer is yes, but not the approach you assumed: classification instead of generation, a far smaller model than the one everyone defaults to, a cache in front of an expensive call. We write down the version that is actually true, including when it costs us the follow-on build.

If you already know you need document extraction, a search layer over your own archive, or a chat interface in your product, and the open questions are about how rather than whether, go straight to that page, document and email processing, knowledge search over your own documents, or AI assistants inside your product. Paying for a study to confirm a decision you have already made is a study you do not need.

What you get

Written report

Whether AI applies, which class of approach fits, extraction, retrieval, classification, generation, or none of those, and why.

Data assessment

What data the approach needs, whether you have it, and in what state, digitized, labelled, structured, it would need to be.

Cost model

Rough running cost at your actual expected volume, not a per-call list price, including the latency budget the use case actually needs.

Risk list

Where the approach is likely to fail or need a human in the loop, named specifically rather than folded into a general caveat.

A recommendation

Including "do not build this" as a valid outcome, with the reasoning written down so it survives past this quarter's decision-makers.

A small prototype where useful

Against a real sample of your data, not synthetic examples, when that is the fastest way to answer the open question.

Scope and estimate for the follow-on build

If there is one, so the next decision has a number attached to it.

When this fits, and when it does not

A good fit

  • You suspect AI could help with a specific problem but do not know which approach fits it, or whether the data you have is actually usable.
  • The cost of building the wrong thing, or the right thing on the wrong approach, is high enough that a few weeks of study is cheap insurance against it.
  • You need a written case to take to whoever approves the budget, and "trust me" is not going to clear that bar.
  • Nobody internally can currently give a straight answer on whether the accuracy or cost you are picturing is even in the achievable range.

Not a good fit

  • You already know exactly what needs building and the open questions are about implementation, not whether it is the right idea. Go straight to the relevant service; paying us to confirm a decision already made wastes your budget.
  • You want a study that is really a rubber stamp for a decision already made. We write down what is actually true, including when that means recommending against what you hoped to hear.
  • You need a working prototype in front of customers next week. A study is scoping work; if you need something built fast, say so and we talk about the build directly.
  • The problem is genuinely small enough that any competent engineer can size it up in an afternoon. A formal study on a decision that obvious is money better spent on the build.

How it runs

  1. 01

    Scope the question

    What decision this study needs to support, and what "done" looks like, agreed before any research starts.

  2. 02

    Look at the real data and workflow

    Not a description of them, because the gap between "we have this data" and "this data is usable" is where most bad estimates come from.

  3. 03

    Test the most promising approach

    Against a real sample, small enough to move fast, real enough that the result means something.

  4. 04

    Model cost and failure modes

    Running cost at your actual volume, and the specific ways the approach is likely to fail, worth planning for before they happen.

  5. 05

    Deliver the report

    And talk it through, including the version where the recommendation is not to build.

Questions we get

What if the answer is "don't build this"?

That is a completed study, not a failed one. You paid to avoid the cost of finding that out after a build, and you keep the report either way.

How long does this take?

Typically two to four weeks. Most of the delay is usually getting access to real data and the right people's time, not the analysis itself.

Do you build the recommended solution afterward?

If you want us to, yes, and the study includes a rough scope and estimate for that. There is no obligation to continue with us if the answer points somewhere else.

Can you evaluate an approach we've already started building?

Yes, that is a common way in: a prototype that works in a demo but nobody is sure will hold up at real volume or real cost is exactly what this checks.

Not sure if AI is the right tool for the problem?

Describe the problem, not a solution you have already picked. An engineer reads it and tells you honestly whether it is worth a study at all.