In production
not a demo that works once on stage
Cost modelled
per-request economics before you commit
Evaluated
quality measured, not asserted
Your keys
your provider account, your data, your control
Pricing
What it costs to find out, then to build.
Discovery is a fixed price and deliberately portable. The build after it is priced per stage against what discovery found, never as one open-ended number.
Discovery sprint
On requestfixed
- Is this an AI problem at all — answered honestly, in writing
- A working prototype on your real data, not a slide
- Cost per request modelled at your expected volume
- The evaluation set: how we will know it is good enough
- A costed build plan you can take anywhere
Deliberately portable. Roughly a third of these end with a recommendation not to build, and that is the sprint doing its job.
Request this ↗AI feature in your product
On requestone-off
- One capability built into what you already run
- Retrieval over your own content where it is needed
- Evaluation suite, so quality is measured not asserted
- Guardrails, fallbacks and a path when the model is wrong
- Cost monitoring per request and per user
For a product that exists and needs one thing it cannot do today.
Request this ↗The full AI product
On requeststaged
- The application, the model layer and the data pipeline
- Agents and tool use where they earn their place
- MCP server, if it should plug into other tools
- Admin, monitoring and cost controls from day one
- Staged delivery, usable at each stage
- 30 days of Care plan after launch
Priced per stage against the discovery plan, so it never becomes one open-ended commitment.
Request this ↗Add-ons — buy with any package or on their own
Care plan
On requestper month
- Model and SDK updates as providers deprecate versions
- Prompt and retrieval tuning against the evaluation set
- Cost review — provider pricing moves, and usually downward
- Monthly note on quality and spend
Model providers deprecate on their schedule, not yours. This is who handles that.
Request this ↗Compare
Side by side.
Whether you are proving it is worth doing, adding one capability, or building the thing.
| What you get | Discovery | AI feature | Full product |
|---|---|---|---|
| Answers whether AI is the right tool | Included | Not included | Not included |
| Working prototype on your real data | Included | Included | Included |
| Cost per request modelled | Included | Included | Included |
| Evaluation suite, quality as a number | Included | Included | Included |
| Built into a product people use | Not included | Included | Included |
| Guardrails, fallbacks and monitoring | Not included | Included | Included |
| Agents, tool use and MCP where they fit | Not included | If needed | Included |
| Staged delivery | Not included | Not included | Included |
| Portable — take it to anyone | Included | Not included | Not included |
Discovery first, always. Roughly a third of them end with a recommendation not to build, and that outcome is far cheaper here than three months in.
Before we start
What your business needs in place.
AI projects fail on data and on definitions, almost never on models.
A definition of 'good enough'
Written down, before anything is built: what a right answer looks like, what a wrong one costs, and how often wrong is tolerable. Without it there is no way to tell whether the thing works, and every review becomes an argument about taste.
The data, and permission to use it
The documents, tickets or records it reasons over — and confirmation that using them this way is allowed. In banking, health and government this is the constraint that decides the architecture, so it comes first.
A provider account in your name
Anthropic, OpenAI or a cloud region. Billing sits with you, keys stay yours, and nothing about the system depends on my account existing.
Someone who can judge the output
A person who knows a good answer from a plausible one in your domain. They spend a few hours building the evaluation set, and that is the highest-leverage time anyone spends on the project.
A real volume estimate
Requests per day and how long an answer may take. Cost and architecture both hinge on it, and the gap between a hundred and a hundred thousand requests is a different system entirely.
Terms
How the money and the risk are split.
No retainer to start a conversation, and no invoice for work that never got delivered.
Half to start, half on delivery
Balance falls due when the work is done and handed over. Not delivered, not charged.
Fixed price, not an estimate
The number holds unless you change the scope. If I misjudged it, that is mine.
The clock starts at handover
From the day I have everything on the list, not from the day you pay.
One round of revisions included
Then hourly, quoted before anything starts. No surprise invoices.
You own everything at the end
Code, accounts, assets and credentials. Nothing is held hostage.
Proof
AI products in production, not demos.
Everything here is running and taking real input.
OurGrowth
A multi-tenant AI marketing platform: 70 skills, an orchestrator and a recommendation engine, all self-optimising against real outcomes.
our-growth.com ↗AI Glossary
A catalogue of Claude skills with structured inputs and outputs, shipped as an npm package and an MCP server.
Agency
An AI marketing platform with 21 agents across 7 departments on a .NET and React stack, built for Egypt and Saudi.
Product and customer engines
Retrieval and ranking against a real catalogue, measured on what people actually bought.
What you get
What the sprint and the build leave behind.
Including the parts that make it maintainable rather than impressive.
A prototype on your real data
Within days, so the decision to build is made on evidence rather than a demo video.
An evaluation suite
Quality as a number that moves, run on every change. The only sane way to argue about a probabilistic system.
Cost and quality monitoring
Per request and per user, so the bill never becomes a surprise at the end of a month.
Your keys, your account
Provider billing in your name. Nothing about the system depends on my account existing.
What you send
The handover, in one list.
Send it in one go and the clock starts.
- What the product should do, in plain language
- Sample data — real, or realistically messy
- Examples of good and bad answers, if you have them
- Access to the product this plugs into
- Expected volume and acceptable response time
- Any compliance rule on where data may go
How it runs
Six steps, and you see each one.
-
01
Frame
What is the actual task, and is a model the right tool for it? Sometimes the answer is a database query.
-
02
Prototype
The smallest thing that proves it works, on your real data, inside days.
-
03
Evaluate
An evaluation set with your expert. From here, quality is a number rather than an opinion.
-
04
Build
The product around it: interface, retrieval, guardrails, fallbacks, monitoring.
-
05
Cost and harden
Per-request cost, rate limits, caching, and what happens when the provider has an outage.
-
06
Ship and hand over
Live, monitored, documented, with the evaluation suite so your team can keep measuring. The 30 days start here.
Scope
What this is not, and who it is not for.
These are quoted separately, so the price above stays a price.
- Model and inference costs — billed to your own provider account
- Training a foundation model from scratch
- Data labelling at volume
- Buying or licensing datasets
- Regulatory approval for automated decisions
- Ongoing content moderation staffing
Right fit, wrong fit
Saves a call that would end in no.
A good fit
- You have a real task, not a mandate to use AI
- There is data, and permission to use it
- Someone in-house can judge whether an answer is good
- You want the cost modelled before committing
- You would rather be told it is a bad idea than sold a build
Not a fit
- The goal is to say the company uses AI
- The data does not exist or cannot be used
- Nobody can define what a correct answer is
- You need a guarantee it is never wrong — nobody can give that
After launch
After it ships.
Model providers deprecate versions, change prices and ship better models on their own schedule. An AI product left alone for a year is running on something more expensive and worse than what is available. The Care plan is who tracks that.
Questions
The ones people actually ask.
Will you tell us not to build it?
Yes, and it happens regularly. That is what the discovery sprint is for, and it is priced so that outcome still leaves you better off than a build that quietly underdelivers.
Whose API keys and whose bill?
Yours, always. The provider account is in your name, the keys stay with you, and nothing depends on my account existing. I have no reason to want your inference bill running through me.
How do we know it is good enough?
An evaluation set built with your domain expert, run on every change. Quality becomes a number that moves up or down, which is the only way to have a sane conversation about a probabilistic system.
What if the model gets it wrong?
It will, sometimes. So the design question is what happens then: a fallback, a human in the loop, a refusal, or a clearly-marked uncertain answer. Which one is right depends on what a wrong answer costs you, which is why that number is a prerequisite.
Which model do you use?
Whichever fits the task, the cost and the residency rules — usually Claude, sometimes not, and it is a decision the discovery makes with numbers rather than a preference I bring with me.
Tell me what you have, and I will tell you what it takes.
The app, the market and the deadline is enough to get a straight answer on scope, price and timing — usually the same day.