The number we’ve seen most often on incoming vendor proposals is eight weeks. It’s not a lie, it’s the best-case outcome for the simplest possible scope, with clean data, a named internal owner, and no surprises. Most operations don’t have all three, and nobody finds that out until week five. Every phase in an AI project has a minimum viable duration. Compress any of them and you’re not saving time, you’re borrowing it from rework.
Why Most AI Project Timelines Are Wrong Before They Start
85% of AI projects exceed their initial timeline estimates. That number isn’t a coincidence, it’s structural.
The vendor incentive problem
Vendors get paid at kickoff, not at value delivery. An optimistic timeline closes the deal. A realistic one loses it to a competitor who is willing to promise faster. The result is that nearly every AI proposal you receive is calibrated to win the work, not to reflect how long the work will actually take.
The fix is to separate the proposal timeline from a scoped discovery output. Any vendor who won’t commit to a discovery phase before giving you a build estimate is guessing, and guessing in their favor.
Data readiness is the variable nobody puts on the timeline
Your data determines your timeline more than your vendor does. Companies with clean, centralized, digitized data deploy AI 40–60% faster than those with scattered or paper-based processes (McKinsey, 2025). Most SMB AI projects don’t discover the data problem until week three of a four-week build, at which point the timeline doubles and the original estimate becomes irrelevant.
Before signing anything, run a quick audit of your own data infrastructure. Know what you have, where it lives, and whether it’s in usable shape, that work belongs to you, not the vendor.
Phase 1, Discovery (Weeks 1–3)
Discovery is the phase most vendors skip or compress to a single kickoff call. It’s also the phase that determines whether everything that follows is aligned or misaligned.
What a real discovery phase produces
A proper discovery phase produces four things: a clearly scoped use case with defined inputs and outputs, a data audit showing what exists and what’s missing, a documented success metric (not a vague “it should work better”), and a risk register covering integration dependencies, data gaps, and compliance constraints.
If a vendor’s discovery deliverable is a slide deck with a timeline and a signature block, they haven’t done discovery, they’ve done pre-sales. Discovery that actually de-risks a project takes one to three weeks and produces working documents, not presentations.
How to know if a vendor is skipping discovery
Ask for the discovery deliverables before you agree to a build scope. If they can’t name specific documents, a use case brief, a data mapping exercise, an integration dependency audit, they’re packaging discovery as part of build and billing you for the rework when it unravels.
Agencies that skip or rush discovery produce three times more rework downstream. That’s not a soft claim, it’s a documented pattern across AI development timelines.
Phase 2, Architecture and Design (Weeks 2–5)
Architecture happens in parallel with the tail end of discovery. This is where the technical approach gets locked: API integration, retrieval-augmented generation (RAG), fine-tuned model, or a combination.
Choosing the right integration type
API integrations (calling an existing model like GPT-4o or Claude via API with prompt engineering) are the fastest path and carry the least technical debt. RAG systems, where you attach the model to your own data via a vector database, take longer to build and require data that’s clean, chunked, and continuously maintained. Fine-tuned models require training data you may not have and expertise that most SMBs can’t maintain internally.
The architecture choice should be driven by the use case requirements, not by what the vendor specializes in. Make sure the recommended architecture is documented and justified before build begins.
Scope definition, where scope creep actually starts
Scope creep doesn’t start in build. It starts here, when the use case is still being defined and every stakeholder adds one more “while you’re in there.” Scope creep in architecture is fatal because it compounds: every addition in design becomes two additions in build and four in testing.
Lock the scope document at the end of Phase 2. Changes after that point should require a formal change order, not because agencies are rigid, but because undocumented changes are how projects go 40% over budget.
Phase 3, Build (Weeks 4–12)
Build duration depends entirely on integration type. A simple API integration with clean data and a single workflow can ship in four to six weeks of build time. A custom RAG system with multiple data sources and a business logic layer takes eight to twelve.
What “build” means for an SMB vs. an enterprise
Enterprise build phases include extensive infrastructure provisioning, security reviews, procurement cycles, and cross-team alignment. SMB builds move faster on most of those fronts, but SMBs typically have less technical staff available to test, review, and unblock issues as they arise.
The constraint isn’t the code. It’s internal availability. If the business owner or operations lead is the only person who can validate whether the output is correct, and that person is running the business full-time, build will stall at every review checkpoint.
Milestones that signal the build is on track
At the midpoint of build, you should be able to run a live demonstration against real (not synthetic) data. If the midpoint demo only works on curated sample data, the team hasn’t encountered your actual data yet, and encountering it in the final two weeks of build is how timelines slip by 100%.
Weekly milestones should include a deliverable you can test: a working endpoint, a sample output batch, a connected data source. “We’re making progress” is not a milestone.
Phase 4, Testing (Should Be 30% of Total Timeline)
Testing is the most systematically underbudgeted phase in AI projects. Most project plans allocate one to two weeks. The number that actually holds up under scrutiny is 30% of total project time, meaning a 12-week project needs roughly three to four weeks of structured testing.
Why testing is underbudgeted
Vendors underbudget testing because it’s the phase that’s easiest to compress on paper and hardest to justify on a sales proposal. “Two weeks of QA” looks fast and professional. “Four weeks of adversarial testing across failure modes and edge cases” looks like padding, even though it’s the difference between a system that works in demos and one that works in production.
AI systems fail differently from traditional software. A bug in conventional code fails deterministically. An AI integration can produce confident-sounding wrong outputs, degrade silently over time as data drifts, and behave differently under load. Testing has to cover accuracy, latency, cost per call, failure modes, and edge cases, not just “does it return an answer.”
What to test beyond accuracy
Test at minimum: output quality across a representative sample of real inputs, latency under realistic concurrent load, behavior at the defined input edge cases, cost per call at projected usage volume, and the fallback behavior when the model returns a low-confidence or malformed output.
If the vendor’s test plan doesn’t include error handling and fallback scenarios, it’s an incomplete test plan.
Phase 5, Deployment and the First 90 Days
Going live is not “done.” Production is where a new phase begins: real users, real data, real volume, and behaviors the test environment didn’t surface.
Production is not the finish line
The first 90 days of production should be treated as a monitored rollout, not a handoff. Usage patterns shift, edge cases accumulate, and model behavior can drift as the underlying model receives updates from the provider. AI integrations built on third-party models, which covers most SMB implementations, require ongoing monitoring that most “go-live and out” proposals don’t include.
If a vendor’s proposal ends at deployment with no defined post-launch monitoring period, ask explicitly what the support structure looks like for the first 90 days. A system that fails silently in month two costs more to fix than the original build.
Metrics that confirm the integration is working
Define success metrics before build, not after deployment. Useful metrics: task completion rate versus baseline, time-per-task delta for the workflow being automated, error rate and escalation rate, and cost per completed task versus the previous process.
“The client seems happy” is not a metric. Organizations with fully integrated AI are nearly 4x more likely to report revenue growth (58%) than those still in the piloting phase (15%), but only when they can measure what changed and why (EY Pulse AI Survey, 2025). That correlation holds when implementation is complete and instrumented; it doesn’t mean integration alone produces growth.
Realistic Timeline Ranges by Project Type
| Project Type | Typical Duration | % Reaching Production |
|---|---|---|
| Simple API integration (single workflow) | 4–8 weeks | ~75% |
| Custom RAG system (own data, 1–3 sources) | 10–16 weeks | ~55% |
| Multi-source RAG or agentic workflow | 14–20 weeks | ~40% |
| Fine-tuned or custom-model implementation | 16–24 weeks | ~30% |
These are realistic ranges for SMB projects with reasonable data readiness and internal availability. Add four to six weeks to any range if data readiness is poor. Add two to four weeks if internal stakeholder availability is limited.
Simple API integrations (4–8 weeks)
An AI layer on top of a well-documented API, email categorization, document summarization, response drafting, can be scoped, built, and tested in four to eight weeks. These integrations carry the least risk because they don’t require you to maintain training data or a vector database.
The risk here is scope creep: “while you’re building the summarization tool, can we also add sentiment scoring?” Each addition resets the test cycle.
Custom RAG systems (10–16 weeks)
RAG systems that retrieve answers from your own documents or databases require more upfront data work and ongoing maintenance. The build itself isn’t dramatically longer, it’s the data preparation and testing that push the timeline to 10–16 weeks.
If the documents you’re attaching to the RAG system aren’t clean, consistently formatted, and reliably updated, the system will produce unreliable outputs regardless of how good the model is.
Complex or fine-tuned implementations (16–24 weeks)
Custom models and complex agentic workflows are enterprise territory for most SMBs. They require training data, specialized expertise, and a long-term maintenance commitment. If a vendor recommends fine-tuning for a use case that could be solved with a well-engineered prompt and a RAG layer, push back.
Frequently Asked Questions
How long does an AI integration really take for a small business?
For a straightforward API integration with clean data, four to eight weeks from discovery to deployment is realistic. Most SMB projects that involve custom data layers or multi-step workflows run 10–16 weeks when done properly. Projects that skip or compress discovery frequently end up at 20+ weeks after rework. The timeline depends more on your data readiness and internal availability than on the complexity of the AI itself.
What happens during the discovery phase of an AI project?
Discovery produces a defined use case with explicit inputs and outputs, a data audit identifying what’s available and what’s missing, a documented success metric, and an integration dependency map. A real discovery phase takes one to three weeks and produces working documents. If your vendor’s “discovery” is a single kickoff call followed by a proposal, they’ve skipped it.
Why do so many AI proofs of concept never reach production?
Gartner puts the PoC abandonment rate at 30–46%. The leading causes are poor data quality discovered mid-build, unclear business value that doesn’t survive contact with real usage, escalating costs as scope expands, and lack of internal ownership once the vendor leaves. Projects without a named internal owner who has time to validate outputs and drive adoption have a much lower production rate regardless of technical quality.
What is the biggest cause of AI project delays?
Data readiness is the single biggest cause of AI project delays. Vendors discover mid-build that the data they were told exists either doesn’t exist in usable form, lives in three incompatible systems, or requires significant cleaning before it can be used. This is compounded by scope changes in the architecture phase and insufficient stakeholder availability during testing.
How much of the timeline should be allocated to testing?
30% is the figure that holds up in practice, roughly one week of testing for every two to three weeks of build. Most proposals allocate far less than this. The gap shows up as post-launch failures, silent degradation, and emergency fixes that cost two to three times what proper testing would have cost. Push any vendor to justify a testing budget under 25% of total timeline.
What should a handoff include at the end of an AI project?
A complete handoff includes system documentation (architecture, data flow, dependencies), prompt version history and the rationale for current prompt design, monitoring runbooks explaining what to watch and what to do when outputs degrade, access credentials and ownership transfer, and a defined escalation path for the first 90 days. Anything less and you don’t own the integration, you’re dependent on the vendor to maintain it. Read more on what a complete handoff looks like in AI integration documentation requirements for handoff.
What does a realistic total budget look like for an SMB AI project?
Budget ranges vary widely by scope, but expect that testing and post-launch monitoring together represent 40–50% of total project cost when done correctly. Many proposals put 80% of the budget in build and leave almost nothing for structured testing and a monitored rollout. That ratio produces systems that work in demos and fail in production.
Most SMB AI projects that succeed run 12–20 weeks from discovery to stable production. Projects that “go live in 8 weeks” and then require three months of firefighting aren’t faster, they’re just front-loading the wins and back-loading the failures.
If you want to talk through what a realistic timeline looks like for your operation, start a conversation. We scope and build this work with defined phases and no fixed-price guessing, see how we approach it at designodin.com/ai.