How to fix a stuck Claude pilot in 21 days.

The instinct on day one is to start writing code. Resist it. Spend the first week understanding why the pilot stalled. Three artifacts come out of week one:

1. Failure mode map. Every place the pilot can break, written down. Auth boundary, tool side effects, prompt drift, retrieval recall, token cost. Each one ranked by likelihood and blast radius.
2. Eval baseline. Twenty to fifty regression cases that represent the pilot's actual job. If you can't write them, the pilot's job isn't defined yet, and that's the real bug.
3. Go/no-go memo. One page. Should this pilot ship? If yes, what gets cut. If no, what to do with the half worth saving.

The go/no-go is the most important deliverable of the week. About one in four stuck pilots shouldn't ship at all, and saying so on day seven is worth more than three more weeks of pretending.

Assuming the pilot earned a go, week two is hardening. Most stuck pilots are stuck because the foundation is soft. Specifically:

• Scoped MCP tools. Every tool gets typed inputs, typed outputs, scoped OAuth, and a kill switch. A tool that can write should require a reviewer queue before any production-grade side effect.
• Auth boundary. Claude never holds raw credentials. It calls a thin server you own. Your server enforces row-level security, not the prompt.
• Token guardrails. Per-session caps, per-day caps, fallback to a cheaper model when context exceeds threshold. Cost dashboards wired up before launch, not after.
• Output validation. Structured outputs validated against a schema. If the parse fails, the request retries with a corrective prompt, then fails closed.
• Audit logs. Every tool call logged with prompt, response, user, timestamp, latency, cost. Pipe to your existing observability stack.

By the end of week two the foundation is boring. Boring is the goal. Boring foundations let the model do interesting work.

Week three is restraint. The single most common reason pilots stall is scope creep: five workflows half-built, none in production. Pick the one workflow with the clearest ROI, ship it, and let the rest wait.

One shipped workflow looks like this:

• Eval suite green on the regression baseline.
• Canary rollout to 5%, then 25%, then 100%, gated on the eval pass rate and cost-per-call ceiling.
• Runbook checked into the repo: rollout, rollback, on-call escalation, known failure modes.
• Dashboard live in your existing observability stack.
• One pair-programming handoff session per week from week one through week three, so your engineers own the build.

By day 21 the workflow is in production. The pilot is no longer stuck. The rest of the roadmap is sequenced on the runbook your team now owns.

About one in four engagements ends with a written "do not ship" recommendation. This is a feature, not a failure. Six months and $400K of engineering time saved by a one-page memo on day seven is the highest-leverage deliverable we have. The half worth saving usually becomes a smaller workflow we ship in 21 days. The half not worth saving becomes a one-page postmortem the team can use to reset expectations with the board.

If you're three months past your original launch date and you still can't answer "is this ready," that's the signal. Start with the $1,000 AI Audit. 48 hours later you'll have the answer.