AI EngineeringAI Product Engineering
AI Feature Sprint
One AI feature built into the client’s own product or system, live in production for an agreed audience behind a switch that turns it off, with monitoring, cost controls, an evaluation baseline their team can rerun, and the architecture and runbook to keep it running.
AI Feature Sprint
$20K–$35K
- Duration: 3 weeks
- Tier: Build
- Format: Fixed scope
You leave withOne AI feature live in production with monitoring and cost controls
Book a Free SessionSound familiar?
We have been told for a year that we need AI in the product. A hackathon demo impressed everyone, but nobody on the team has the time or the experience to turn it into something we would put in front of customers. I do not know how to stop it making things up, what it will cost per user once it is live, or how we would know it had started getting worse. I need it in production, not another demo.
What you leave with
Feature in production
Format: Code in the client’s repository, deployed behind a switch
How we know it’s acceptableRuns for the agreed audience. The off-switch has been tested. Monitoring shows live traffic.
Evaluation set and baseline
Format: Versioned cases and scripts in the client’s repository
How we know it’s acceptableScored against the agreed measures and rerunnable by their team without us.
Monitoring and cost controls
Format: Dashboards, alerts and cap configuration
How we know it’s acceptableAn alert has fired in a test. Cost per call is measured against the agreed ceiling.
Reference architecture, runbook and QA checklist
Format: Markdown or PDF in the repository, plus a paired session
How we know it’s acceptableThe client’s technical owner diagnoses a seeded fault using only the runbook at handover.
How it runs
3 weeks
Week 1
Define and design
Failure definition, success measures, data and permission design, and the release path confirmed.
OutA one-page spec and agreed evaluation measures. Gate: the client accepts the spec and the release path.
Week 2
Build and instrument
Feature working in staging with tracing and cost metering. First evaluation run. By the end of the week, a rehearsal deploy to production behind the switch, to prove the path.
OutWorking feature in staging with traces.
Week 3
Evaluate, release, hand over
Evaluate against the baseline and fix. Staged release to the agreed audience. Monitoring and alerts live. Paired handover.
OutLive feature, evaluation baseline, runbook.
Is this right for you?
This is for you if
- Buyerthe person who owns the product or system the feature goes into: a CPO, head of product, CTO or technical founder.
- Also has to say yeswhoever signs off security and data use, and whoever controls releases. The release owner is the one most often missing, and a feature that cannot ship in week 3 is a feature that misses the promise. Finance, if the price is above their discretionary limit, which varies by client.
This is the wrong answer if
- The feature needs to take actions across other systems, with several steps and approvals. That is an agent and the answer is Agent Prototype Sprint.
- The client cannot release to production within three weeks. A change freeze, a quarterly release train or no deployment pipeline means the feature ends in staging, and the promise is production. Do not sell this.
- Security or data-use approval cannot be completed before day one, or no approved model provider exists yet.
- The work is deterministic. A rules engine or script is cheaper and easier to audit.
- The client wants a roadmap of features, or has not decided which one. Start with Agent Opportunity Blueprint or AI Opportunity & Roadmap Sprint.
- The client has a working prototype and needs it hardened. That is not this programme.
What’s included, and what isn’t
In scope
- one feature
- production and staging environments
- up to two integrations or data sources
- one model provider
- monitoring and alerts
- cost controls
- an evaluation set and baseline
- staged release to the agreed audience behind a switch
- handover
Out of scope
- a second feature
- changes to the client’s own systems beyond the integration points
- data cleanup
- fine-tuning or training a model
- design work beyond the minimum to host the feature
- hosting commitments
- production support and on-call after handover, which is Managed Services — Essential and priced separately
- security certification
- rollout beyond the agreed audience
Before we start
Before day one
- Repository access and an environment we can commit to.
- The deployment pipeline is known, a named release owner can ship in week 3, and there is no change freeze.
- Security and data-use approval is recorded, and an approved model provider exists.
- A named technical contact who can answer the same day.
- Sample data representative of the real thing, not a cleaned subset.
- Agreement on what a wrong answer costs and who decides the acceptable error rate.
- A decision-maker who can resolve scope questions within 24 hours.
What we’ll need from your team
- A platform or product engineer: four hours a week, for access, schema and deployment questions.
- The release owner: two hours in week 1 and three in week 3.
- A product owner or domain expert: two hours a week, to say whether outputs are right.
- A security or data owner: one to two hours in week 1.
- A decision-maker available within 24 hours when the scope question arrives.
Pricing
What we need to give you a quote
- The feature in one sentence and where it lives.
- Users and expected volume.
- Data sources, and whether permissions are enforced at retrieval or in the application.
- The target environment and release process.
- Status of security and data-use approval and which model providers are approved.
- Sample data that is representative, not a cleaned subset.
- The monthly cost ceiling.
- Whether it ships to one tenant or all.
After we hand over
Who owns it after we leave
A named engineer on the client’s platform or product team owns the runbook, the evaluation set and the monitoring. A product owner owns the decision when quality drifts.
It displaces reviewing alerts and rerunning evaluations before any model or prompt change: roughly two to four hours a week at launch.
If the client names no owner, the handover stays open as a decision. It is not an implied support commitment.
What we measure
- Agreed in week 1 and reported at handover: accuracy on the evaluation set, wrong-answer rate, p95 latency, and cost per call.
- Client-measured: the product metric the feature was meant to move, such as time saved, usage or conversion, taken before launch and at 30 days.
What comes next
- A second feature sprint
- Eval Harness Sprintwhere the client wants evaluation in CI across features.
- Managed Services — Essential($5K–$10K a month) once the feature is live.
- Agent Prototype Sprintif the next need is an agent.
- Agent Scale Launchfor multi-workflow agent systems.
- AI Engineering Pod — Standardfor a client with several features and no team.
Questions buyers ask us
You can build the demo. What takes longer is the evaluation set, monitoring, cost caps and the release path. If your team has done that before, you should not buy this.
If your need sits inside their data boundary, use theirs. This is for features inside your own product and data.
This is a fair objection. It is credible only if your release path and approvals are ready on day one, which is the intake gate. If they are not, we will not sell it and we will say why. We would rather lose the sale than miss the date at a fixed price.
Nothing, completely. In week 1 we agree what a wrong answer costs, design for it with grounding, refusal and human fallback, and measure the rate on an evaluation set. You get a measured rate and an alert threshold, not a promise.
We measure cost per call in staging and in production for the agreed audience and set caps. The number is in the handover, before volume grows.