How long does a Claude Code project take? Phases, gates and what slows it down
How long does a Claude Code project take? Phases, gates and what slows it down
No honest vendor can tell you how many weeks a Claude Code project will take before they have seen your site, your codebase and how fast your team can make decisions. What they can tell you is the phases the work goes through, what has to be true to move from one phase to the next, and what can cause delays. That is a better basis for planning than a promised date.
Claude Code can shorten the part of a project where code gets written. It does not shorten waiting for access, waiting for approvals, gathering content and facts, or the human review that every AI-written change needs. On a website project, those parts can easily decide the calendar.
This guide walks through the phases of a Claude Code website project, what each one depends on, the things that slow projects down, and what you can do before the vendor starts to keep yours moving.
Key Takeaways
- Plan by phases and gates, not by promised weeks. Agree target dates after discovery, once both sides know the codebase.
- Several big time factors sit on your side: access, approvals, content and facts, and how quickly someone can review work on staging.
- Faster code generation doesn't remove review. Each batch of changes still needs a person to read the diff, run a check and approve it.
- For site moves with URL changes, Google says that for medium-sized sites "it can take a few weeks or more" for it to start showing the new URLs, and larger sites take longer.
- Launch is not the end. Plan a post-launch phase for fixes, monitoring and handover.
The phases of a Claude Code website project
| Phase | What happens | Gate to move on | What it depends on |
|---|---|---|---|
| 1. Discovery | Review the site, codebase, platform, risks and goals | Written plan, risk list and access plan approved | Access to look at the site and code; a decision-maker's time |
| 2. Access and setup | Repository in git, staging copy, Claude Code configuration and permission rules | A test change runs end to end on staging and is reviewed | How quickly accounts and roles are granted |
| 3. Planning | Detailed plan for the changes, often in Claude Code's plan mode before any edits | Plan approved by your project owner | Clear requirements and decisions |
| 4. Build in batches | Changes made on branches, in reviewable batches | Each batch reviewed, checked and accepted | Review capacity on both sides; content and facts arriving |
| 5. QA and acceptance | Full checks: build, links, redirects, structured data, forms, browser review | Acceptance criteria met | Agreed criteria; your testing time |
| 6. Launch | Deploy through your normal process with a named approver | Live checks pass | Hosting and DNS access; a launch window |
| 7. Post-launch and handover | Fixes, monitoring, documentation, access removal | Handover accepted | Time to review the handover pack |
A team rollout follows a similar path, with a pilot and training in place of the build. Our scope-of-work template sets out those phases and their gates.
Why Claude Code doesn't make the whole calendar shorter
Claude Code works through tasks by gathering context, taking action and verifying results. On a well-prepared repository it can make and test a large change in one session. But a project is more than its coding steps.
- Review takes human time. Every diff needs a person to read it and every visual change needs someone to look at it in a browser. A batch that took minutes to generate can take much longer to review properly, and it should.
- Decisions wait for people. Which pages to keep, which design details matter, what a price or claim should say: Claude Code can't decide these for you.
- Facts come from you. On content-heavy jobs, someone has to supply and approve prices, service details and claims.
- Some steps can't be rushed. DNS changes, search engines processing a site move, and third-party approvals run on their own clocks.
What slows Claude Code projects down
| Cause | Why it slows things | How to prevent it |
|---|---|---|
| Access arrives late | Work can't start on the real codebase or staging | Prepare accounts and roles before kickoff (see the onboarding checklist) |
| No git or no staging copy | These have to be set up before any safe work begins | Set them up first, or budget a setup phase |
| Unclear decision-maker | Gates stall while people disagree | Name one approver per gate |
| Content and facts not ready | Pages are built, then rebuilt when real content arrives | Gather content and approve facts early |
| Platform specifics | WordPress or Shopify keep some content and settings in a database or admin, which adds steps | Discuss in discovery; plan how changes move from staging to live |
| Scope added mid-project | Every addition needs planning, review and testing | Use a change-request process; park ideas for a later phase |
| Skipped review, then rework | A missed error spreads across many pages and has to be undone | Review every batch; check more than the first result |
| Integrations and third parties | Waiting on another vendor's access or answers | Identify them in discovery and contact them early |
| Regulated or legal review | Healthcare, legal and financial content may need sign-off | Book reviewers' time in advance |
Nearly every cause in this table is about preparation and people, not about the tool. Our agency onboarding checklist covers the access to have ready on day one.
What one real rebuild looked like
When we rebuilt eseospace.com with Claude Code, moving roughly 2,227 URLs off WordPress to a static build, the new site went live on its new host on 23 June 2026, the day after the first commit. That date reflects our own situation: our team owned every decision, approved every deploy and had all access from the start. It is not a promise for any other project.
Two other details from that rebuild matter more for planning. The first attempt, a clean Next.js rebuild that stripped the theme's JavaScript, was abandoned on day one because it broke animations, accordions, widgets and menus; a person decided to keep the theme's own scripts instead. And the work didn't stop at launch: by the end of September 2026 the repository had 496 commits, including an accuracy audit that applied more than 4,400 corrections across about 750 pages. Our guide to rebuilding a website with Claude Code covers the full process.
Timing for site moves and search engines
If your project changes URLs, part of the timeline is outside your control. Google's site move documentation says to "expect temporary fluctuation in site ranking during the move," that for medium-sized sites "it can take a few weeks or more" for Google to start showing the new URLs, and that larger sites take longer. It recommends keeping redirects "generally at least 1 year." Build that into your expectations, and keep your redirect map tested; our guide to building a 301 redirect map explains how.
How to read a proposed timeline
- Look for phases and gates, not just an end date. Each phase should say what must be true to move on.
- Check what is assumed about you. A good timeline lists your dependencies: access by a certain point, content by another, an approver available.
- Find the review time. If the plan has no time for reviewing diffs and testing on staging, the dates are unrealistic or the review is being skipped.
- Ask what happens if a gate fails. The answer should be a fix-and-recheck loop, not "we'll catch it after launch."
- Be wary of guaranteed dates before discovery. A vendor who promises a launch date without seeing your codebase is guessing.
Pricing and timing are linked: a fixed price needs a firm scope, and a retainer spreads work over months. Our comparison of fixed-price vs retainer Claude Code work explains the trade-off.
What you can do to keep a project moving
- Name one project owner who can approve gates and make decisions quickly.
- Have repository, staging, hosting and analytics access ready before kickoff, with the right roles.
- Gather content, brand rules and approved facts before the build phase.
- Block time on your calendar to review each batch on staging.
- Agree acceptance criteria early, so QA is a check, not a debate. Our website QA routine shows the checks worth running before every deploy.
- Keep a list for "phase two" so new ideas don't reopen the current scope.
Conclusion
A Claude Code project's timeline is decided by its phases, its gates and the people around it more than by how fast code can be written. Ask for a plan built on phases and dependencies, set target dates after discovery, protect review time, and plan for the weeks after launch. If you're planning a migration, see our website migration services, or our Claude Code development service for rebuilds and builds. More guides are in our Claude Code Guide.
Frequently asked questions
Can you give me a typical number of weeks?
Not reliably. The same job can take very different time depending on the state of the codebase, the platform, how quickly access and content arrive, and how much review the work needs. A timeline agreed after discovery is far more useful than a typical figure.
Does Claude Code make projects faster?
It can shorten the coding steps. It doesn't shorten approvals, content gathering or the review every change needs, and no vendor can guarantee a speed-up.
Which delays can I prevent?
Many of the causes in the table above, such as late access, unready content and an unclear decision-maker, sit on your side, so they are the best place to start. Platform quirks, third parties and search engines are harder to control, so plan time for them.
Should launch be the last phase?
No. Plan a post-launch phase for fixes, monitoring, search engines processing any URL changes, and handover of documentation and access.
Should I agree dates before discovery?
Agree a date for discovery itself. Set dates for later phases once both sides have seen the codebase and know the dependencies.
Put this into action with eSEOspace
We help businesses grow with seo, geo & aeo that actually performs. Explore the services behind this guide:
Get a FREE Audit
We'll perform a comprehensive SEO, AEO, GEO & CRO audit of your website — completely free — and show you exactly how to outrank your competitors.
Don't have a site yet? Get in touch →
Get a FREE GEO/AEO/SEO Audit
We'll analyze your site's SEO, GEO, AEO & CRO — completely free — and show you exactly how to get found across Google and AI answers.
Don't have a site yet? Get in touch →
Great — your audit is on the way!
We'll send your free SEO/GEO/AEO/CRO audit within the next few hours. Where should we send it?
You're all set! ✓
Your free audit is being prepared — check your inbox in the next few hours. Talk soon!
On this page
- Key Takeaways
- The phases of a Claude Code website project
- Why Claude Code doesn't make the whole calendar shorter
- What slows Claude Code projects down
- What one real rebuild looked like
- Timing for site moves and search engines
- How to read a proposed timeline
- What you can do to keep a project moving
- Conclusion
- Frequently asked questions
