Most AI projects miss their date for one reason: the demo proved the easy 20% of the problem, and everyone planned the schedule as if that was the whole job. The fix is to scope the boring 80% (data, integration, evals, edge cases) before you commit a date, and to tell the client what "done" actually requires.
I run delivery for a living. I've watched a flawless Friday demo turn into a three-month grind, and it almost always traces back to the same planning mistake. So let me walk through where the time actually goes, and how I scope around it now.
The demo is a measurement of capability, not reliability
A demo runs on inputs someone hand-picked. The data is clean, the user cooperates, the happy path is the only path. That's not cheating. It's what a demo is for. But it removes every condition that makes the real system hard, which is exactly why a working prototype tells you so little about the delivery date.
The pattern holds across the industry: a polished pilot runs six to twelve weeks, and the production deployment behind it runs six to twelve months. Most AI failures come from organizational and operational issues, not the model itself. When I read a plan that assumes the demo timeline carries through to launch, I know where the slip is coming from before the project even starts.
Where the time actually goes
When I break down a real AI build, the model work is a slice, not the cake. The hours hide in:
- Integration with systems nobody documented. Legacy interfaces, auth that was never designed for machine access, a CRM with twelve years of inconsistent data. Teams routinely spend most of their build time here, on connectors, not on the agent.
- Data readiness. Cleaning, structuring, and governing the data is real engineering, and it lands on the schedule whether you planned for it or not. A lot of projects stall here.
- Evals. You cannot say a feature is done until you can measure that it's done. Building that measurement is a deliverable in its own right.
- The unglamorous edge cases. The 20% of inputs that aren't clean are where the agent compounds small errors into a wrong answer a customer sees.
None of this shows up in a demo. All of it shows up in the burndown.
How I scope it now
I stopped estimating from the demo. I estimate from production requirements, and I define those before anyone writes a prototype. That mirrors what we argue at Shanti Infosoft in The AI demo works. That's the problem. define what production needs first, then build toward it.
My scoping checklist before I commit a date:
- What's the real input distribution? Not the demo's three examples. The messy thousand.
- What systems does this touch, and who owns the integration on their side? Undocumented interfaces are the single most common reason my estimates need a buffer.
- How will we know it works? If we can't write the acceptance test, the feature isn't scoped, it's wished for.
- What happens when the model is wrong? A human in the loop, a fallback, a confidence threshold. This is design work, and it takes time.
- Who operates this after launch? Monitoring and ownership are part of "done," not a phase-two afterthought.
Then I add a buffer where the risk is highest, usually integration and data, and I make that buffer visible to the client rather than burying it. A schedule with no buffer isn't optimistic. It's wrong, and everyone finds out at the worst possible time.
Key takeaways
- A demo proves capability under ideal conditions. It does not predict your delivery date.
- Plan for the 80% the demo skips: integration, data readiness, evals, edge-case handling, and operations.
- Pilots are weeks; production is months. Estimate from production requirements, not the prototype.
- If you can't write the acceptance test, the feature isn't scoped yet.
- Put the buffer where the risk lives, and show the client why it's there.
FAQ
How long does a real AI project take? It depends on integration and data complexity, but the honest framing is that a polished pilot in six weeks can still need months of production hardening. Scope the hardening explicitly instead of discovering it.
Why do AI estimates miss so often? Because they're anchored to the demo. The demo removed the hard conditions on purpose, so estimating from it skips the work that actually consumes the schedule.
What's the single best way to de-risk an AI timeline? Define what "done" means in production before you prototype, write the acceptance tests, and buffer the integration and data work.
If you're staring at a great AI demo and trying to figure out the real timeline behind it, that's a conversation I have every week. The team at Shanti Infosoft is happy to walk through your scope and give you an honest read on what production will actually take.
