Your AI Pilot Is Stuck. Here’s the 6-Week Playbook to Get It Into Production.

Every founder we talk to with a stuck pilot describes a version of the same scene. The demo was great. The team was excited. A six-week engagement turned into four months. The vendor got slower to reply. The AI technically works, but no customer touches it, no process depends on it, no number on your P&L has moved. And now every meeting ends with some flavor of “are we throwing good money after bad?”

You’re not an outlier. MIT’s NANDA Project reported in 2025 that 95% of enterprise generative AI pilots produce no measurable P&L impact. That number is widely cited, and it’s accurate, but it doesn’t tell you what to do about your pilot, this week, with the budget you have left. That’s what this piece is for.

We’ve rescued more than 40 stuck pilots in the last 18 months. The patterns repeat. So does the fix.

The real problem is the gap between demo and production

Your pilot’s model is probably fine. GPT-4o-mini, Claude Sonnet, a fine-tuned open-weight model. In almost no rescue we run is the model itself the thing that’s broken.

Here’s what actually breaks. A demo needs five things to work: a prompt, a model, an input, an output, and a happy user watching the output appear. A production system needs about thirty. Authentication, rate limiting, error handling, observability, audit logs, data pipelines, permissioning, graceful fallback when the model is down, human review on anything high-stakes, drift monitoring, a documented owner, a support process, a cost cap. The list goes on.

Pilots built on vibe-coding platforms like Lovable, Bolt, or Cursor without engineering guardrails tend to nail the first five and skip the other twenty-five. The demo looks beautiful. Then a real workflow tries to depend on it, and every missing piece turns into either a bug or an outage. Trust collapses, and the project quietly dies in staging.

RAND’s 2024 study on AI project failure root causes found 80.3% of AI initiatives fail, roughly twice the rate of non-AI IT projects. McKinsey’s 2024 State of AI survey echoes the pattern: adoption is up sharply, but only a sliver of organizations have moved AI from experimentation into production. Menlo Ventures put a dollar figure on it. $547 billion of the $684 billion enterprise AI spend in 2025 produced no measurable results. The money wasn’t wasted on models. It got burned on the gap between model and system.

Rescue work almost always lives in that gap.

Why your pilot stalled: the five patterns we see every time

Every rescue we’ve run fits one or more of these five. If three of them describe your pilot, you’re in rescue territory. If four or five fit, you may be in restart territory, and the Week 2 decision below will tell you which.

1. The pilot was scoped to impress, not to ship

The original SOW optimized for the wow moment in a stakeholder meeting instead of the daily workflow that an employee or customer would actually use. Signs: one hero use case and a long tail of edge cases nobody planned for, or the thing works perfectly on three cherry-picked inputs and falls apart on the fourth. The fix is almost never “more AI.” It’s redefining success as consistent performance on the top twenty real-world inputs, not peak performance on three handpicked ones.

2. Your data wasn’t production-ready, and nobody told you

Pilots run on clean, curated sample data. Production runs on messy, incomplete, inconsistent real data. If the handoff from pilot to production skipped the data-readiness audit (missing fields, inconsistent formats, access permissioning, PII handling), the system stalls the moment real inputs hit it. Teams in healthcare, finance, and legal get hit hardest here, because HIPAA, GDPR, and SOC 2 requirements weren’t baked in at the pilot stage.

3. It was vibe-coded on tools that don’t scale

Lovable, Bolt, Cursor, and v0 are brilliant for a 48-hour prototype. They’re not where production lives. We’ve opened the hood on dozens of stuck pilots and found no observability, no version control discipline, no tests, no error boundaries, hard-coded API keys, and architecture that assumes a single user at a time. That’s not an engineer’s mistake. That’s the default output of those tools. Rescuing this type of pilot rarely means scrapping the UI or the prompts. Those are usually fine. What gets rebuilt is the plumbing underneath.

4. Nobody owns the handoff

The pilot vendor delivered. The internal team said “great, we’ll take it from here.” Then nobody did. Engineering is on another project. Ops doesn’t know how to monitor an LLM in production. The vendor’s contract ended. The pilot sits in staging, half-live, for weeks or months. We see this pattern on about a third of our rescues, and it’s the easiest one to resolve once someone names it out loud.

5. The original contract had no production clause

If the pilot contract paid the vendor on milestones that ended at “demo delivered,” there was never contractual pressure to make the pilot production-ready. Vendors ship what they’re paid to ship. If “produces working output in a sandbox” was the payment trigger, that’s what you got. This is why Dezy’s own AI Production Build contracts tie final payment to a working SOW date, not a demo. The pressure to ship real sits on us, not on you.

The 6-week rescue playbook

The sequence below is what we run on nearly every rescue. You can’t harden a system before you’ve diagnosed it, and you can’t hand it over until it’s hardened, so the week order is firm. What flexes is scope inside each week, based on how much of the pilot is salvageable.

Week 1: Diagnose

Nothing gets touched. The whole week is listening, reading code, and interviewing the people around the pilot. The person who commissioned it, the engineer who built it (if they’re still around), the user who was supposed to adopt it, and the ops lead who inherited it. Our diagnosis template covers 42 specific checks across code quality, data readiness, security, cost, observability, and business fit. The deliverable is a plain-English report and a clear binary recommendation: rescue or restart.

Week 2: Decide (and set kill criteria)

This is the week that quietly decides whether the rescue works. Three things get locked.

Scope

Exactly which use cases are in-scope for production and which get formally cut. Cutting is harder than it sounds. We’ve had rescues where the biggest win in Week 2 was walking back three ambitious use cases down to one.

Metrics

The two or three numbers that will tell you in 30 days whether the rescue worked. Not model accuracy. Business metrics. Calls deflected, tickets resolved, hours saved, revenue attributed. If you can’t name those numbers, you don’t have a rescue yet, you have a hope.

Kill criteria

The specific conditions under which both sides agree, in writing, to stop. Rescues work better when both sides can walk away without drama. If 70% of real-world inputs still fail eval scoring after Week 4, we stop. That clarity protects your budget and our reputation.

Weeks 3 and 4: Rebuild and harden

Most of the engineering lives here. Vibe-coded surfaces get wrapped in production-grade infrastructure. We keep what’s good (usually the UI and the prompts) and replace what won’t scale (usually the plumbing). By end of Week 4 the system has observability, cost controls, evals running against real data, and compliance posture appropriate to the industry.

Week 5: Ship

Phased rollout. 5% of users first, then 25%, then 100% within the week. The rollout is instrumented so if any metric degrades past agreed thresholds, the system auto-reverts. By Friday of Week 5 the AI is live, real users are on it, and the metrics from Week 2 are being tracked daily.

Week 6: Handover

Documentation. Incident playbook. 30-day watch period, often transitioning into an AI Operations Retainer at $500 to $1K per month for ongoing monitoring, cost optimization, and quarterly updates. Your team owns the system end-to-end by Friday. Code, infrastructure, credentials, all of it transfers to your accounts.

Rescue or restart? The Week 1 decision framework

Not every stuck pilot is worth rescuing. Here’s how we draw the line.

Rescue usually runs $8K to $18K across six weeks. Restart runs $15K to $35K across ten to fourteen weeks. The restart premium isn’t the rebuild cost. It’s the cost of re-earning stakeholder trust after a failed first attempt. Rescue preserves that trust. Restart has to rebuild it from scratch, often while the budget is already under pressure.

If you’re not sure which category you’re in, our 14-day AI Build Sprint exists for exactly this question. $4K, fixed price, written diagnosis and a rescue-or-restart call at the end. For roughly 2% of a typical rescue budget, you find out whether the rescue is worth doing before you commit to it.

What a production-ready AI system actually looks like

If you’ve never seen one up close, here’s the shape of the system you’re aiming at. Seven non-negotiables we check before we’ll call a rescue done.

1. 1

   One named owner on the business side. Not the vendor. Not IT. Someone whose quarterly goals depend on this AI working.

2. 2

   Observability. Every AI call logged with input, output, latency, cost, and user. You can answer “what did the AI say to user X on Tuesday at 3pm” in under a minute.

3. 3

   Evals on real data. A running test set of 20 to 100 real inputs with expected outputs, re-run on every change, with pass thresholds that have to be hit before anything ships.

4. 4

   Cost controls. Hard spend caps per day and per user, automatic alerts, documented cost per successful outcome.

5. 5

   Graceful fallback. When the model is down, the system degrades without the user noticing. No error screens, no broken flows.

6. 6

   Human-in-the-loop where stakes demand it. Any output that touches money, safety, or legal risk routes to a human review step before it takes effect.

7. 7

   A documented incident playbook. One page. Says exactly what to do when the AI starts producing bad output. Updated after every incident.

Pilots ship with none of these. Production systems ship with all seven. Weeks 3 to 5 of the rescue is where you build the gap.

What the fix looks like in practice

Case texture matters here, so a quick one. A health-tech founder we worked with earlier this year had an AI triage assistant stuck in staging for five months. The original pilot had been built in Cursor by a two-person team. The prompts were good. The UI was clean. The system had no auth, no HIPAA posture, no observability, and no way for the team to see what the AI was telling patients.

Week 1 diagnosis took three days. Week 2 we cut two of the three original use cases, kept the strongest one, and set two business metrics (triage completion rate and nurse-escalation accuracy). Weeks 3 and 4 we rebuilt the auth layer, added full prompt logging, wired evals against 60 real patient interactions, and hit HIPAA posture. Week 5 we rolled out to 15% of users on a Tuesday and 100% by Friday. Week 6 we trained the client’s ops lead and handed off.

Total time, six weeks. Total cost, $14K. The system is still live and handling triage for the client. We have more examples like this in our case studies if you want to see what the pattern looks like at other scales.

The main points to take away

• Most AI pilots stall at the gap between demo and production, not at the model.
• Five patterns cause nearly every stall: scoped to impress, data not production-ready, vibe-coded tooling, no handoff owner, no accountability clause.
• Rescue costs $8K to $18K and takes six weeks. Restart costs $15K to $35K and takes ten to fourteen.
• The Week 2 decision (scope, metrics, kill criteria) is the one that quietly determines whether the rescue works.
• Production-ready AI has seven non-negotiables. Your pilot has probably zero.
• The honest question isn’t “was this a mistake?” It’s “what’s the shortest path from here to a working system?”