Two weeks is a realistic timeline for a focused marketing site, provided the scope is clear and decisions get made quickly. AI tools have made the build faster, but they haven’t changed what makes these projects slip: unclear content, late feedback and scope that keeps growing. This is the plan we use for a site of roughly six to ten page templates, and where AI helps at each stage.
Before day one: what has to be true
A two-week site is possible when:
- One person on the client side can make decisions and is available for short daily check-ins.
- The brand exists. Logo, colours and typefaces are settled, even if loosely.
- The goal of the site is agreed: book demos, collect enquiries, support a launch, or recruit.
- Most of the content exists in some form, even as a rough document.
If any of these is missing, fix it first or plan for longer. No amount of tooling makes up for a missing decision-maker.
Days 1–2: structure and content
We start with the sitemap and a content outline for each page: its purpose, the main message, the sections in order and the call to action. This is the most important work in the project and it stays human-led, because it depends on understanding the business.
Where AI helps: turning interview notes and existing material into a first-draft outline, suggesting section structures from comparable sites, and rewriting long internal documents into shorter page copy that the client then edits. Drafts are a starting point. Every line of final copy is reviewed by someone who knows the product.
Where it doesn’t: deciding what the company should say, which audience matters most, or what to leave out.
Days 3–5: design system
Rather than designing every page, we design the pieces pages are made from: a type scale, spacing, colour tokens, buttons, and about fifteen to twenty content sections (hero, feature grid, proof section, pricing table, FAQ, call to action). Then we show those sections assembled into the two or three most important pages.
Where AI helps: generating layout variations for a section quickly so the designer can react to options instead of starting from a blank canvas, and filling designs with realistic content so nobody signs off on lorem ipsum.
Where it doesn’t: taste. Choosing which variation is right, and making the system feel like one brand, is still design work.
The client reviews on day five. We ask for consolidated feedback in one round.
Days 6–9: build
Engineering starts on day five or six, building components directly from the design system. We use a static-first framework (usually Astro) with a headless CMS or Markdown content, depending on who will edit the site.
Where AI helps most: this is where the time savings are largest. An engineer can describe a component, get a working first version, and spend their time on the details that matter: responsive behaviour, accessibility, motion, edge cases in content length. Models are also good at writing CMS schemas from a content outline, generating test content for every component state, and writing redirect maps from an old sitemap.
What we still do by hand: review every change, test with a keyboard and screen reader, check layouts at awkward widths, and make sure the CMS fields make sense to a non-technical editor. Generated code that looks right but fails an accessibility check or breaks at 360px wide is common. Review is not optional.
By the end of day nine every template is built and populated with real content on a staging URL.
Days 10–11: content entry and QA
The client’s team enters or reviews final content in the CMS, which doubles as training. We run a structured QA pass:
- Performance against agreed targets (for example, LCP under 1.5 seconds on a mid-range phone).
- Accessibility checks, automated and manual, against WCAG 2.2 AA.
- Cross-browser and device testing on real hardware.
- Forms, analytics events and consent banners tested end to end.
- Metadata, social previews, structured data and sitemap checked.
Where AI helps: drafting meta descriptions and alt text for review, scanning pages for broken links and inconsistent terminology, and writing automated tests for forms.
Day 12: launch
Launch day should be uneventful. DNS changes are prepared in advance, redirects from the old site are in place, and we test the live site immediately after the switch. We submit the sitemap to search engines and watch error logs and analytics for the rest of the day.
Days 13–14: buffer and handover
We keep two days in reserve, because something always comes up: a late content change, a legal review of a page, an integration that behaves differently in production. If nothing does, we use the time for a handover session, a written editor’s guide and a list of recommended next improvements.
What makes the timeline slip
In our experience it is rarely the build. The common causes are:
- Content that arrives late. Designing and building around placeholders creates rework.
- Feedback from people who weren’t in the room. A senior stakeholder seeing the design for the first time on day ten is the most expensive event in the project.
- New pages mid-project. Each one is reasonable on its own. Together they add a week.
- Integrations discovered late. A CRM or booking system that needs connecting should be in the scope on day one.
The honest summary
AI has made the build phase of a marketing site meaningfully faster, and it has made drafting and QA cheaper. It hasn’t shortened the parts that depend on people agreeing what the site should say. A two-week timeline works when the team protects those decisions, keeps feedback to scheduled rounds, and treats AI output as a draft that someone qualified signs off.
