How Our Small Team Runs a Four-Week Website Rebuild Sprint

TL;DR #

Four weeks is a tempo, not a marketing line. It works when scope is locked: one domain, under thirty core pages, content that mostly exists, no major stack change. Week one is audit and IA. Week two is visual direction plus core page designs. Week three is build, CMS wiring, SEO basics. Week four is QA, migration, launch, handoff. The client hands over old-site assets in week one, signs off on design in week two, finishes English copy review by mid-week three. Slip any of those a day and the whole sprint slips a day. There is no hidden buffer. The flow below has run on a dozen real projects, and the bottlenecks listed are ones we have walked into.

When this fits #

A four-week sprint usually fits when:

• The old site is alive, so we can pull content, cases, and product images.
• Page count is under thirty, which usually means eight to twelve unique page types.
• Brand basics (logo, palette, type) exist, or the client will reuse the old visual system.
• The decision chain is short. The founder or one named owner can sign off in twenty-four hours.
• No deep ERP or CRM integration. Standard SMTP or a webhook for forms is enough.

We push to six to eight weeks when scope adds a second language, when content has to be rebuilt from PDFs or a dead CMS, when the brand system itself is being redesigned, or when three layers of internal approval are involved. Forcing those into four weeks usually costs you English review or QA, and the site comes back for rework two weeks after launch.

For cost and timeline ranges by page count, see Website Renovation Cost and Timeline.

Week 1 #

No code in week one. Every hour goes into figuring out what the current site actually has, what is worth migrating, and what should be cut.

Audit #

We run the site through Complete Website Renovation Audit Checklist row by row. The output is a spreadsheet with every URL, traffic, backlinks, indexation, and a quality grade. A two-hundred-page legacy site usually drops to thirty or fifty worth bringing across. The rest gets merged, 301'd, or returned 410.

The judgment calls are harder than the work. A client's "News" section may have eighty trade-show write-ups from before 2019. SEO value: basically zero. But the marketing director sees "company history" and wants to keep them. Our move is to put numbers on the table. Those eighty posts brought eleven sessions and zero inquiries in the last twelve months, and dragging them across dilutes the topical signal we are trying to build. The client makes the call. We just make sure the evidence is there.

Information architecture #

The IA only makes sense after the audit. We draw it as a tree in Figma: what sits under each top-level menu, which case study each service page links to, what shows in the footer. Drawing the tree forces two answers:

• What should an overseas buyer see in the first three seconds?
• From homepage to submitted inquiry, how short can the path be?

Without those, the IA can't move forward, and every downstream design is a guess.

Content inventory and stack plan #

Two deliverables before the weekend. Content inventory: old URL to new URL mapping, copy fields that need rewriting, assets the client still owes. Stack plan: CMS, hosting region, CDN, form handler, multilingual scope, analytics.

End of week one: audit, IA, inventory, stack plan. Client signs off Friday, or week two can't start.

Week 2 #

The first week the client sees something. Visual direction, core page designs, and copy drafting starts.

Visual direction #

We don't show three options. Three options will stretch a project to six or eight weeks. We show one direction with reference sites and the rationale: why this palette, why this type pairing, why a full-bleed hero instead of a side nav. The review is a half-day session with the founder and marketing lead. Wrong direction, we adjust the same day. Right direction, we go straight into page-level design.

Given three options, clients reliably pick the wrong one. Not because of taste, but because the least striking option always feels safest in a side-by-side.

Core page designs #

Not all thirty pages get high-fidelity mocks. Five or six core templates do: home, service page, case detail, about, contact, blog detail. Everything else inherits from those. Deliverable is the high-fidelity Figma at desktop and mobile breakpoints.

Copy in parallel #

Design and copy run together from mid-week onward. The client's content owner sends one English draft per day, and we (or a contracted native writer) return edits the same day. If copy slips into week three, QA in week four is what takes the hit.

End of week two: design system, core templates, first English drafts. Client confirms direction and homepage copy by Friday.

Week 3 #

Build week. The workload peaks here. Three people run in parallel: a front-end developer, a CMS engineer, and the content/SEO owner.

Build and CMS #

The front-end assembles components while the CMS engineer wires up WordPress or a headless setup (Strapi plus Next.js, for example). Both sides align on field names on Monday so the front-end doesn't get an API in week four with mismatched keys.

The common blow-up is the client adding a new module mid-week. The founder sees a competitor's comparison table and wants one. Our move is to write it into the backlog with hours attached ("eight hours, which means eight fewer QA hours") and let the business owner pick what to drop. Don't be agreeably vague. A four-week sprint has no hidden buffer.

Forms and conversion paths #

Service pages and the homepage get a WhatsApp button (setup in WhatsApp Business Setup Checklist). Form fields capped at five. UTMs on every entry. Submission tested three ways: success, missing field, email-not-arriving (usually SPF or DKIM).

SEO basics #

The SEO owner closes out: per-page titles and meta descriptions written one at a time, Organization and Service schema, first-pass internal links, sitemap.xml, robots.txt audit, GA4 and Search Console. Launch-day requirements, not "we'll add it after."

Content migration #

Pages that survive the audit need 301 redirects. This step looks easy and has the highest defect rate of anything in the sprint. We run Website Content Migration Checklist line by line: URL mapping, image re-optimization (WebP or AVIF), outbound link updates, case-study permissions re-checked. One missed 301 on a high-traffic page can cost you twenty percent of organic traffic in the two weeks after launch.

End of week three: working staging site, every core page, forms and buttons working, SEO foundations, 301 map. Client finishes staging proofread by Sunday.

Week 4 #

The tightest week. QA, performance, migration, launch, handoff. Five things in five days.

QA #

A fixed checklist:

• Every page on Chrome, Safari, Firefox, and Edge, desktop and mobile.
• Form submission tested with three real inboxes, including the auto-reply.
• WhatsApp button clicked on a real phone, with the correct pre-filled message.
• Every link, internal and external, clicked once. No 404s.
• Image alts, SEO titles, and descriptions crawled with Screaming Frog to flag missing fields.

This step does not get skipped, and it does not go to the client. The client proofreads copy. QA is engineering work.

Performance #

Lighthouse pass targeting mobile Performance above 75 and Accessibility above 90. Common fixes: uncompressed images (convert to WebP), render-blocking scripts (defer or remove), paint-blocking fonts (font-display: swap). If the audience is in Europe, we run WebPageTest from Frankfurt with a target under three seconds to first contentful paint.

Migration and launch #

Two scenarios. Same-domain rebuild: 301 map applied before DNS cutover, smoke test the new build, rollback plan written. New domain: full-site 301, address change in Search Console, partners notified.

We launch on Tuesday or Wednesday. Never Friday. A Friday launch means either the team works the weekend or the client lives with a broken site for two days. Tuesday leaves three working days to fix anything that surfaces.

Handoff #

Four things go to the client on the last day:

• Ops doc: hosting, CDN, domain, email, CMS credentials. Shared via 1Password or Bitwarden, never email.
• Editor guide: how to edit each page type, image upload conventions, the flow for publishing a blog post.
• SEO dashboard: Search Console and GA4 entry points, with a one-page note on weekly checks.
• 30-day review calendar: day-7, day-14, and day-30 sessions booked to review data together.

For the longer maintenance arc, see Post-Launch Website Maintenance Checklist.

Client moves #

A four-week sprint is half us and half the client. The fastest project we ever ran had assets in our hands by Wednesday of week one. The slowest one, same scope on paper, had the client still arguing internally about a product name translation in week three.

Non-negotiable from the client side:

• Week 1: old-site CMS access, GA and Search Console permissions, raw assets for every product and case study.
• Week 2: sign off on visual direction and homepage copy. No major IA changes after this.
• Week 3: staging site copy review with one round of feedback per day.
• Week 4: a daily 15-minute sync, plus someone available on launch day for the DNS cutover.

A three-layer approval chain (staff to marketing director to CEO) is the single biggest schedule risk on a sprint. We surface this at kickoff and ask the CEO to join the weekly sync directly for sprint decisions, skipping the middle layer.

Common slowdowns #

A dozen sprints in, the same things keep breaking the schedule:

• Missing assets: case photos promised Friday, but permissions are still sitting with the client's legal team. Prevent it by logging permission status for every case in week one.
• Endless copy edits: the founder rewrites the hero every Monday. Prevent it by locking homepage copy at the end of week two and billing later edits hourly.
• Brand team appears late: the parent company suddenly mandates a unified template in week three. Prevent it by confirming brand scope at kickoff.
• DNS or email owned by a third party: domain in a former employee's personal account, email run by a previous agency. Prevent it by starting the ownership transfer in week one, not on launch day.
• Surprise multilingual ask: "let's add Spanish" a week before launch. Prevent it by writing into the contract that four weeks equals a single language.

Sprint at a glance #

FAQ #

What does a four-week sprint cost? #

Pricing depends on page count and feature complexity. Service sites under ten pages typically land between USD 9k and 15k. A thirty-page site with multiple cases and a blog template runs USD 18k to 28k. Module breakdown in Website Renovation Cost and Timeline.

Can we add scope mid-sprint? #

You can, but additions go into the backlog with hours attached, and the business owner picks what gets dropped to make room. There is no hidden buffer, so adding one thing means cutting another. That trade-off is why the sprint format works.

What about post-launch support? #

We cover bug fixes for fourteen days after launch (not new feature requests). Day-7, day-14, and day-30 review sessions are included. Ongoing content and SEO is a separate monthly engagement; see Post-Launch Website Maintenance Checklist.

Multilingual in four weeks? #

Not recommended. A single-language sprint already runs at full capacity. Adding a language doubles translation, review, hreflang, and QA. Our default is to launch English first, then run a four- to six-week follow-up sprint for German or Spanish.

Get a diagnosis #

If you're planning a rebuild, or you launched and results came in below expectation, bring your existing site, target markets, and team setup. We'll run a free initial review under our website rebuild service using this sprint framework: what fits in four weeks, what needs six to eight, which items are P0 regardless of timeline.