The honest answer is a range, not a number: two to six weeks from a scoped starting point to a working system. Which end of that range you land on comes down to a small number of decisions made before any building starts, not to how good the technology happens to be that month.

I get asked this question on nearly every discovery call, usually early, usually before we've talked about scope at all. That's backwards, and it's worth explaining why, because the order those two conversations happen in tells you almost everything about whether a timeline estimate is going to hold up.

Where the clock actually starts

Implementation timelines don't start on day one of the engagement. They start once the scope is clear, and getting there usually takes its own week or two before any building begins.

The assessment is what makes that possible: a structured discovery call plus a scored survey that produces a readiness score, a prioritized roadmap, and a governance baseline. It sounds like a formality. It isn't. Skipping it doesn't save time, it just moves the scoping work into the middle of the build, where it's more expensive to do and where every wrong assumption costs you a redo instead of a conversation.

I've watched this go both ways. A contractor who spends two hours in an assessment call, answering honestly about where their data lives and how their team actually works day to day, walks into the build phase with almost no surprises left. A business that wants to skip straight to "just build the thing" usually discovers halfway through that nobody agreed on what "the thing" was supposed to do. That discovery costs a week, sometimes two, and it costs it at the worst possible point in the schedule.

What actually determines two weeks versus six

Once scope is set, four factors do almost all the work of predicting where you'll land on the range.

None of these factors are about how capable the AI itself is. They're about how tangled your existing operation is, and how much of that tangle needs sorting out before a new tool can sit on top of it cleanly. That's usually the part people underestimate going in.

I understand the instinct to think a faster model or a fancier vendor shortens the timeline. It rarely does, not by much. The bottleneck almost never sits with the AI itself, which can draft a document or answer a query in seconds regardless of which underlying system is running it. The bottleneck sits with your data, your review process, and your team's availability to test and learn the thing. A business that's organized internally will move quickly with almost any competent AI tool behind it. A business that isn't will move slowly no matter how impressive the underlying technology happens to be, and no vendor pitch changes that math.

A two-week build, in practice

Picture a small excavation company that wants AI help drafting proposals faster. One workflow, one person using it, data already living in a handful of past project folders that are reasonably organized. The assessment confirms the scope in a day or two. The build itself, template setup, testing against real past proposals, a short training session with the estimator, fits into two weeks comfortably, because there's nothing else competing for that time.

A six-week build, in practice

Now picture a mid-sized manufacturer wanting AI woven into engineering documentation, where a regulator expects a clean audit trail and three separate document types have to update in sync. Data lives across an old shared drive and a newer project management tool that only half the team actually uses. Getting the data question sorted takes real time on its own. Governance has to be designed carefully enough that it survives an audit, not just a demo. None of that is a criticism of the business, it's just a harder problem with more moving parts, and six weeks reflects that honestly rather than being padding.

What the weeks actually contain

It isn't weeks of waiting on a vendor. It's design, build, and deployment against your actual data, tools, and workflows, with governance, ownership, data boundaries, quality checks, and team training built in from the start rather than tacked on at the end. That's also why both "two weeks" and "six weeks" include a working, trained, governed system when they're done, not a prototype that needs a second engagement to become something your team can actually use.

A rough shape for a two-week build looks like this: a few days confirming scope and gathering the specific data the workflow needs, most of a week building and testing against real examples from your own business rather than generic samples, and the final days training your team and fixing whatever the training session surfaces. Longer builds stretch each of those phases and usually add a phase in the middle for integration testing, where the new workflow has to prove it plays well with tools you're already using.

What happens after launch

A system doesn't finish evolving the day it launches, and pretending otherwise sets up a bad expectation. AI tools keep improving, your business keeps changing, and the workflow that fit your operation on day one will need adjusting six months later, usually in small ways rather than large ones.

That's why an ongoing monthly arrangement, cancel anytime, exists for continued iteration, new use cases, and governance oversight as usage grows. It's a separate, optional phase from the initial build, not a hidden extension of it dressed up as something new. Some clients take it. Some don't, and check back in when something specific comes up. Both are reasonable choices depending on how much your operation changes year to year.

Why AI timelines get compared to the wrong thing

Most business owners have a mental model for how long software projects take, built from experience with ERP rollouts, website rebuilds, or that CRM migration that ran four months over. That experience leads people to expect either instant results, because AI demos always look instant, or a long drawn-out project, because that's what "new software" has meant in the past. Neither model fits well.

AI implementation for a specific workflow is closer to hiring and training a very capable new employee for one part of your operation than it is to installing a new piece of enterprise software. You wouldn't expect a new hire to be fully productive on day one, and you also wouldn't expect training them to take six months. Two to six weeks, with a real person reviewing the output the whole way through, sits about where that comparison would put it.

The comparison breaks down eventually, everything does, but it's a more useful starting point than either extreme people usually arrive with.

What stretches a timeline past the estimate

Sometimes a two-week build turns into four, and it's worth being honest about why, because the reasons are almost always the same handful of things and none of them are exotic.

Data access delays are the most common. Someone who has to grant access to a shared drive is on vacation. An IT contractor who manages a legacy system takes a week to respond to an email. These aren't AI problems, they're ordinary business logistics problems that happen to sit in the critical path of an AI build.

Scope creep is the second. Halfway through building a proposal-drafting workflow, it's tempting to add "and also handle the follow-up emails" or "and also pull in the old CRM data." Sometimes that's the right call. More often it's better as a second phase, because bundling it into the first build means neither piece gets finished on time and neither gets tested properly before going live.

The third is a mismatch between who's available to train and when. If the one person who needs to learn the new proposal workflow is out running job sites all week, the build can be finished and sitting there unused for days before training actually happens. That's not a technology delay, but it shows up as one if nobody accounts for it going in.

Questions worth asking before you commit to a timeline

A few questions tend to separate a realistic estimate from a hopeful one, and they're worth asking whoever gives you a number.

If those answers feel vague, the timeline attached to them probably is too.

Can you pay to go faster?

Sometimes, within limits. Compressing a build usually means running phases in parallel that would otherwise happen in sequence, gathering data while governance gets designed, for instance, instead of one after the other. That works up to a point.

Past that point, speed stops being a budget question and starts being a risk question. A regulated documentation workflow still needs its review structure tested properly before it touches a real audit trail, and no amount of budget makes that testing take less real-world time. I'll tell a client honestly when a request to go faster is reasonable and when it's asking me to skip a step that exists for a good reason. Usually it's obvious which is which once you're looking at the actual workflow instead of a general idea of it.

What if you don't know what you need yet?

That's normal, and it's exactly what the assessment is built to sort out. Most people who reach out don't arrive with a fully scoped project. They arrive with a feeling: proposals take too long, the engineers spend all their time on paperwork, nobody knows where a job stands until someone calls to ask.

Turning that feeling into a scoped workflow with a real timeline is the actual first deliverable, before any building starts. It's also the part that determines everything downstream, which is why rushing past it to get to a number tends to produce a number that doesn't hold.

Why "how long" is really "how much scope"

The honest way to answer "how long will this take" for your specific business is to first answer "what exactly are we building," which is what the assessment exists to sort out before either of us commits to a number. Two weeks and six weeks are both realistic answers to the original question. Which one applies to you depends on decisions that, if you're asking this question today, probably haven't been made yet.

That's not a dodge. It's the actual shape of the problem. A contractor asking how long a renovation will take gets the same kind of answer, and for the same reason: it depends what's behind the walls.

Take the free assessment →