The integration was never scoped
The demo ran on a spreadsheet and nobody checked whether the real system would cooperate. The most common diagnosis by a distance.
An agent designed around a write endpoint the ERP does not expose.
Capability
AI Build Rescue
For the AI pilot that impressed everyone in the demo and then stalled before production. We take it over, find what it is actually missing, and either get it live on a fixed scope or tell you to stop.
From $3,500 · 2–3 weeks to diagnosis · fixed scope, agreed in writing
- To a written diagnosis
- 2–3 weeksTo a written diagnosis
- Fixed, for the diagnosis
- $3,500Fixed, for the diagnosis
- With the cost of each path
- Go / no-goWith the cost of each path
- The findings, whoever builds next
- YoursThe findings, whoever builds next
What your team gets
What is actually delivered
Not a strategy deck. A running system, the permissions around it, and the code in your repository.
- A written diagnosis of why it did not ship, specific enough to argue with
- A go / no-go recommendation with the cost of each path
- An assessment of what in the existing build is worth keeping
- The integration tested properly, usually for the first time
- If go: the production work, on a fixed scope
- If no-go: the findings, yours to take to whoever builds next
What we build
Six ways an AI pilot stalls, and what each one needs
We have yet to find a seventh. The diagnosis is usually one of these, and occasionally two at once.
Nobody would approve the write
It works, it is accurate, and it stalled at read-only because there was no mechanism for a person to review what it wanted to change.
A finance lead who cannot see or undo what the agent would do, so it never gets to.
Accuracy is unmeasured
It seems good. Nobody can say how good, because there is no held-out set and no agreed definition of correct. Without that, it cannot be approved and cannot be improved.
A classifier everyone likes and nobody can defend in a meeting.
No owner, no tests, no logs
A prompt chain in a notebook, one contractor who understood it, and no way to tell when the output drifted after a model update.
Output quality that quietly changed three months ago and nobody noticed.
Cost per run makes it unviable
It works, and at production volume the model bill exceeds the saving. Usually recoverable by routing cheap steps to cheap models, sometimes not.
A workflow costing more per document than the person it replaced.
It solved the wrong problem
Built well, aimed badly. The automated step was not the expensive one, and nobody measured before starting.
A ten-minute task automated while the two-day reconciliation continues by hand.
How we build it
How the rescue runs
A rescue is diagnosis before treatment. We do not start rewriting anything until we can say, in writing, what is actually wrong — and sometimes the finding is that the existing build is sound and the blocker is organisational rather than technical.
- 01
Read what exists
The code, the prompts, the logs if there are any, and the history. Much of the answer is usually visible in the first day, in what was never written down.
- 02
Test the integration
A real read and a real write against the systems it was meant to reach. This is where the majority of stalled pilots turn out to have been stopped.
- 03
Measure the accuracy
A held-out set built from real cases, and a number where there was previously an impression. You cannot approve what you cannot measure, and neither can your risk team.
- 04
Price the paths
Fix, rebuild, or stop — each with a cost and a timeline. Sometimes the existing work is 80% there; sometimes it is a demo that cannot become a system, and saying so is the value.
- 05
Execute, or hand back
If it is worth shipping, we ship it on a fixed scope. If it is not, you get the findings and owe nothing further.
What we can usually keep
Prompts and the domain knowledge inside them are usually worth keeping — someone spent real effort learning what the model needed to be told. Evaluation cases, where any exist, are gold. The orchestration layer is the part most often rewritten, because notebook-era code rarely survives contact with retries, concurrency and logging.
- Prompts
- Usually keep. Real knowledge is in them.
- Eval cases
- Keep, and expand.
- Connectors
- Keep if they handle failure at all.
- Orchestration
- Usually rewritten.
When we say stop
We recommend stopping when the automated step was not the expensive one, when the model cost per run exceeds the saving and cannot be routed down, or when the system it depends on genuinely cannot support the write. That verdict has cost us build work more than once, and it is the reason clients come back with the next project.
- Wrong target
- The step was not costing enough.
- Unit economics
- Cost per run exceeds the saving.
- Hard limit
- The system cannot accept the write.
- No owner
- Nobody will run it after handover.
Working with the original team
Most rescues involve someone’s existing work, sometimes an in-house team and sometimes another vendor. We write the diagnosis about the system rather than about the people, and we would rather hand them a plan they can execute than take the work. That is not always what happens, but it is where we start.
Where it lands
What this looks like in your industry
Manufacturing
A defect-detection pilot with no measured accuracy and no route to the line.
Distribution and logistics
An ordering agent that stalled the moment it needed to write to the ERP.
E-commerce and retail
A support assistant that is accurate in testing and unapproved in production.
FinTech and financial services
A document pipeline blocked by audit requirements nobody designed for.
Institutions and membership
A member chatbot built on an export that is now six months stale.
Healthcare and pharmacy
An extraction pilot with no confidence threshold and no human check.
Technology
What we build agents with, and what we connect them to
We pick the boring option unless there is a reason not to — the framework is the part most likely to be abandoned before your system is.
- Diagnosis
- Code and prompt review
- Log archaeology
- Held-out evaluation set
- Cost-per-run modelling
- Evaluation
- RAGAS
- DeepEval
- promptfoo
- pytest
- Custom rubrics
- Observability retrofit
- Langfuse
- LangSmith
- OpenTelemetry
- Sentry
- Structured logging
- Rebuild targets
- LangGraph
- Model Context Protocol
- FastAPI
- Celery
- Temporal
- Models and routing
- OpenAI
- Anthropic Claude
- Llama
- DeepSeek
- Cheap-model routing
- Ship it
- Docker
- GitHub Actions
- AWS
- Staged rollout
- Runbook and handover
How the engagement runs
Five phases, each with something you can hold
Every phase ends in a named deliverable. You can stop after any of them and keep what has been built.
- 01Week 0
Discovery call
What was built, what it does today, and where it stopped. We say whether a rescue is the right shape or whether you are better starting again.
DeliverableA written next step, free - 02Week 1
Read and test
The code, prompts and logs reviewed, and the integration tested properly against the systems it was meant to reach — usually for the first time.
DeliverableFindings from code review and integration test - 03Week 2
Measure
A held-out set built from real cases and an accuracy number produced, so there is something to approve or reject rather than an impression.
DeliverableMeasured accuracy on real cases - 04Weeks 2–3
Diagnosis and paths
The written diagnosis, what is worth keeping, and each path — fix, rebuild, stop — priced with a timeline.
DeliverableWritten diagnosis and priced go / no-go - 05If go
Production work
The write path, the permission model, evaluation in CI, logging and the deployment — on a fixed scope quoted from the diagnosis.
DeliverableProduction system, tests, source code, runbook
Why Devs Core
Six reasons that are checkable
Diagnosis before treatment
Fixed price for the diagnosis, and no obligation to continue. We would rather be right about what is wrong than be hired to rebuild it.
We test the thing nobody tested
The integration. It is the most common cause of a stalled pilot and the least often checked before the build began.
We measure what was never measured
A held-out set and a real accuracy number, because unmeasured accuracy is why a working pilot cannot get approved.
We will tell you to stop
When the step was not expensive enough, the unit economics do not work, or the system cannot accept the write. That verdict has cost us build work.
We keep what is worth keeping
Prompts and evaluation cases usually carry real knowledge. Starting from zero is rarely the right answer and always the more profitable one for a vendor.
The findings are yours
Whether we build the fix or not. Several rescues have ended with the client’s own team executing the plan.
Questions
AI Build Rescue — the questions we get asked
What is AI build rescue?
AI build rescue is taking over an AI project that was built, works in some form, and has not reached production. It begins with a fixed-price diagnosis: reviewing what exists, testing the integration it depends on, measuring accuracy against real cases, and producing a written go / no-go with the cost of each path — fix, rebuild, or stop.
Why do most AI pilots stall before production?
Almost always one of six reasons: the integration was never scoped, nobody would approve the write, accuracy was never measured so it cannot be approved, there is no owner or tests or logs, the cost per run exceeds the saving, or it automated a step that was not expensive in the first place. The diagnosis establishes which.
What does the diagnosis cost and how long does it take?
AI Build Rescue starts at $3,500 for a diagnosis delivered in two to three weeks. If the recommendation is to proceed, the production work is quoted separately as a fixed scope from the findings. If the recommendation is to stop, you keep the findings and owe nothing further.
Do we have to let you rebuild it?
No. The diagnosis is written so your own team or another vendor could act on it, and several rescues have ended exactly that way. We are paid for the diagnosis regardless of who executes the fix.
Will you work with the team that built it?
Where they are still involved, yes, and we write the diagnosis about the system rather than about the people. Handing an in-house team a plan they can execute is a better outcome than taking the work, and we start there.
What if the original build is unsalvageable?
We will say so, and say what is worth carrying forward. Prompts and evaluation cases usually contain real domain knowledge worth keeping even when the code is not; notebook-era orchestration rarely survives contact with retries, concurrency and logging.
Can you rescue something built with no documentation?
Usually. Code, prompts and whatever logs exist tell most of the story, and a week is normally enough to establish what it does and where it stops. Absent documentation is itself a finding, because a system nobody can explain is one nobody can safely operate.
How is this different from the readiness audit?
The audit decides what to build before anything exists. The rescue diagnoses something already built that has not shipped. If you have a working pilot that stalled, this is the right one; if you are still deciding where to start, the audit is.
Tell us which process is costing you.
Thirty minutes, no preparation, no deck. You describe what keeps going wrong and we tell you whether AI is the answer — including when it is not.
Prefer email? contact@devs-core.com