AI feature feasibility sprint
A fixed-price, fixed-scope sprint for teams with an AI feature in mind and no proof yet that it can be made reliable or economic — ending in a decision, not a deck.
From £4,500
Last updated:An AI feature feasibility sprint is a fixed-scope assessment of one proposed LLM feature or workflow before a build is committed: candidate models and architectures are compared against a representative sample of your data, an initial evaluation set scores them, and a working spike settles the riskiest technical question where code is the only honest answer. Revenant Systems delivers a go, no-go, or change-scope recommendation with a recommended production design and an implementation estimate — from £4,500.
Who is the sprint for?
The sprint fits teams that know where an LLM could help but not whether the feature can be made reliable or economic: a bounded workflow in mind, representative data available, and a build decision waiting on evidence. It suits a first AI feature and a proposed addition to an existing product equally — the question is the same.
- A specific feature or workflow in mind
- Representative sample data available
- No working implementation yet
Who is it not for?
Teams that have already built the feature: the AI production-readiness audit assesses an existing prototype or live feature, and the sprint would repeat work already done. It is also the wrong fit for an organisation-wide AI opportunity review — the sprint answers one engineering question about one feature, in depth.
What does the sprint cover?
One tightly bounded feature or workflow, taken from discovery to a recommendation: suitable model and architecture approaches compared against your sample data, a small evaluation set that scores them, a working spike where one is needed, and estimates of production cost and latency, with security and data-handling observations recorded as they arise.
Model candidates come from Anthropic, OpenAI, Google, and OpenRouter, with local models through LMStudio and llama.cpp where UK data residency rules a hosted API out — judged on your data rather than a public benchmark.
- Model and architecture comparison
- Initial evaluation set
- Working spike where the risk demands it
- Production cost and latency estimates
- Go / no-go / change-scope recommendation
What answer does the sprint end with?
A recommendation you can act on: build it as designed, do not build it, or build a different version of it. Each arrives with the evidence behind it — evaluation scores, cost and latency numbers, the recommended production design — and an implementation scope and budget range, so a yes can proceed without a second scoping exercise.
UK company and contracting entity · UK GDPR-aware delivery · Vendor-neutral model selection · Private and self-hosted deployment options
What you receive
- A written recommendation — go, no-go, or change-scope — with the evidence behind it
- A model and architecture comparison run against your sample data
- An initial evaluation set your team keeps and can re-run
- Production cost and latency estimates for the recommended design
- An implementation scope and budget range, ready to act on
How the engagement runs
- Fixed scope and fixed price — from £4,500, agreed before work starts
- One tightly bounded feature or workflow per sprint
What we need from you
- A representative sample of the data the feature would work on
- A walkthrough with whoever owns the workflow today
- The technical constraints the feature must live within — systems, residency, deployment
Access and client data are handled under our information security statement.
Frequently asked questions
What if the answer is no?
Then the sprint has done its job. A no arrives with the evidence — where quality fell short, what being wrong would cost — and it costs a fraction of discovering the same thing after a build. You keep the evaluation set and the findings either way.
Is the spike production code?
No — a spike exists to settle the riskiest question quickly, and it is written for that. What carries forward into a build is the evaluation set, the model choice, and the recommended design; the build stage then produces code engineered for production.
How is this different from the AI production-readiness audit?
Timing. The sprint runs before anything is built and answers whether it should be; the audit runs after a feature exists and answers whether it will survive production. A sprint that ends in a build tends to meet the audit's checklist on the way through, because the same engineer applies the same standard.
Each package is an audit or assessment offered on its own — the process behind it is covered in how we work.
Have a feature in mind and no proof yet? Let's talk.
Get in touchYour message is read by the engineer who would scope the work; the reply is a short technical conversation.