The honest answer is: it depends. But "it depends" without explaining what it depends on isn't useful. This post breaks down real timelines by project type, the phases that make up each one, and the three factors that cause the most delays.
Typical timelines by project type
These are ranges from actual completed projects, not marketing estimates. The lower end assumes clean data, clear scope, and available stakeholder time. The upper end reflects what happens when any of those conditions are missing.
| Project type | Typical timeline | What drives toward the longer end | |---|---|---| | RAG chatbot (internal) | 4–8 weeks | Poor data quality, many source systems, compliance requirements | | RAG chatbot (customer-facing) | 6–10 weeks | Add: safety testing, brand review, load testing | | AI agent (single workflow) | 6–10 weeks | API integration complexity, error handling edge cases | | AI agent (multi-workflow) | 10–16 weeks | Multiple integrations, routing logic, eval suite breadth | | AI voice agent | 6–10 weeks | Phone system integration, low-latency tuning, call flow testing | | SaaS MVP with AI features | 10–16 weeks | Full stack: auth, billing, UI, AI layer, deployment |
These are build timelines, not calendar timelines. A 6-week build that requires weekly stakeholder reviews and has a two-week data preparation phase before development starts takes 10+ calendar weeks.
The five phases of an AI project
Every project we run goes through the same phases. The durations vary, but the phases don't.
Phase 1: Discovery (1–2 weeks)
This phase defines what we're actually building. Not the AI solution — the business problem.
What happens: stakeholder interviews, current workflow mapping, data inventory, integration identification, success metric definition. The output is a scoped technical spec that defines the boundaries of the system, the data sources it will use, and how quality will be measured.
Discovery often surfaces misalignments between what was requested and what will actually solve the problem. A week of discovery is worth a month of building in the wrong direction.
Phase 2: Architecture (1–2 weeks)
With the spec defined, we design the technical architecture: data pipeline, retrieval approach, model selection, integration points, deployment environment. For RAG systems, this includes chunking strategy and embedding model selection. For agents, this includes tool definitions and memory design.
The eval plan is written during architecture, not after build. The test cases you'll use to measure quality at launch are defined before a single line of LLM code is written.
Phase 3: Build (3–8 weeks depending on scope)
Development, integration, and iterative prompt engineering. Weekly check-ins with stakeholders to review behavior on real examples. A staging environment available for testing throughout.
Most of the timeline variance happens in this phase. See the delay causes section below.
Phase 4: Evaluation (1–2 weeks)
Systematic testing against the eval suite defined in phase 2. This is where quality gates get enforced. A system that doesn't pass eval doesn't ship. This phase also includes load testing for customer-facing systems and security review for anything that touches sensitive data.
Phase 5: Deployment and handoff (1 week)
Production deployment, monitoring setup, documentation, runbook creation, and knowledge transfer. By the end of this phase, your team can operate and iterate on the system independently.
The three biggest delay causes
1. Data problems discovered mid-build
The most common cause of timeline overruns. A company says "we have all our product documentation in Confluence" — then we pull it and find 40% is outdated, 20% is HTML exported from a legacy system with broken formatting, and the rest exists in three different structures.
Data problems don't get smaller when you ignore them. They get bigger. Every week of data cleanup that happens during build is two weeks of delay, because the build is blocked and the evaluation can't proceed on bad data.
The fix: data audit in phase 1, before a contract is signed. We inventory the actual data, not the intended data.
2. Scope creep during build
"While we're building the order status agent, can we also add returns? And maybe account changes?" Each addition sounds small. The aggregate is not small.
Every meaningful scope addition requires updating the architecture, adding tools, expanding the eval suite, and retesting. A project that doubles in scope doesn't take twice as long — it takes three times as long, because the complexity compounds.
The fix: change requests go through a defined process. Small additions that fit within existing architecture are absorbed; material scope changes require timeline and budget adjustments.
3. Integration surprises
Third-party APIs that are documented as REST but actually require a custom SDK. Legacy systems with undocumented authentication flows. "We have a webhook" that turns out to be a batch export that runs nightly.
Integration work is consistently underestimated because the unknowns only become visible during the build. A nominal integration that looks like two days of work in the spec turns into ten days when the actual API behavior doesn't match the documentation.
The fix: spike the integrations in phase 2 before committing to the build timeline.
How to compress timeline without cutting corners
If you need to move faster, the best options in order of impact:
Narrow the scope. A single-workflow agent in 6 weeks is better than a multi-workflow agent in 16 weeks. Ship the narrow version, prove it works, then expand.
Prepare data before kickoff. If you start the project with clean, structured, accessible data, the build phase starts on day one instead of week three.
Have a fast-decision stakeholder available. Projects that require five business days to get an answer on a design question accumulate weeks of delay. One person with authority to make product decisions, reachable same-day, cuts timelines materially.
Don't compress the eval phase. It's tempting to skip or abbreviate testing when you're under deadline pressure. The eval phase is the only thing standing between you and a production incident in week two after launch. Keep it.
What influences the pricing
Timeline and cost move together. A 4-week RAG build for an internal tool is a fundamentally different project than a 12-week customer-facing agent with compliance requirements. If you're trying to understand what your specific project might cost, start with our pricing overview or get in touch directly — we can scope your project in a single call.