Category: AI

“Two weeks” sounds like a corner has been cut somewhere. It has not — but the shape of the fortnight is genuinely different from a traditional build, and the difference is worth explaining rather than asserting.

Here is roughly how a marketing site of eight to twelve pages actually runs.

Days 1–2: Decisions, not design

Nothing gets built in the first two days. We work out what the site has to do, who it is arguing with, and what each page is responsible for. We agree the page list and, more usefully, the page list we are not building.

This is the first place we deliberately slow down. Every hour skipped here reappears later as a rebuild, and a rebuild is expensive precisely because everything else is now cheap.

Day 3: The design system, once

Colours, type, spacing and the base components get defined as tokens before a single page exists. This is the highest-leverage day of the project. Because every section afterwards references those tokens rather than hard-coded values, changing the brand blue in week two is a one-line change instead of a two-day audit.

Days 4–7: Sections, in sequence

This is where the speed lives. Pages get built section by section — hero, then proof, then services, then pricing — and each one is checked before the next begins. Nothing is built in a batch and reviewed at the end, because a fault in the third section propagates into everything downstream if you do not catch it in the third section.

A section that would have been a day of front-end production is now under an hour. That single change is most of where the six weeks went.

Days 8–9: Content

The second deliberate slowdown. Real copy replaces working copy, real images replace placeholders, and every claim on the site gets checked against something true. This is also, reliably, the stage that slips — not because it is hard, but because it depends on people outside the build providing specifics only they have.

If a two-week project becomes a three-week project, this is almost always where it happened.

Days 10–11: The unglamorous pass

Metadata, structured data, redirects, sitemap, analytics, forms tested end to end with real submissions, every page checked on a real phone rather than a resized browser window. On traditional timelines this is the work that gets compressed when the schedule tightens. Here it gets its own days.

Days 12–13: Review and revision

You go through the site properly and we change what needs changing. Because the design system is centralised, most revision requests at this stage are minutes rather than days — which means we can say yes to them instead of negotiating.

Day 14: Launch

DNS, SSL, caching, a final crawl, and a monitored first twenty-four hours. The third deliberate slowdown: we do not launch on a Friday, and we do not launch and disappear.

What the compression is actually made of

Six weeks did not vanish into a trick. Roughly four came out of front-end production, one came out of revision cycles that used to require rebuilding rather than retokenising, and one came out of the QA and fixing pass that a token-driven system largely prevents.

Discovery, content and launch care take exactly as long as they always did. They are the parts that decide whether the site works.

The pitch you have probably heard is that AI makes web development ten times cheaper. The reality is less dramatic and more useful: AI collapses one part of the budget almost completely, leaves another part untouched, and quietly makes a third part more important than it used to be.

Knowing which is which is the difference between a quote that holds and a quote that doubles.

Where a traditional build spends its money

On a conventional agency project, the hours land roughly like this: discovery and strategy, design, front-end production, integration and testing, then content population. Production — turning approved designs into working, responsive, cross-browser pages — is historically the single largest line item. It is also the least interesting work on the project.

What AI actually removes

Production is the line that collapses. Work that used to take a front-end developer several days per template now takes hours, and the output is more consistent than hand-written code because the same tokens get applied everywhere without anyone getting tired at four in the afternoon.

Two smaller lines shrink alongside it. Cross-browser and responsive fixes largely disappear, because the markup was generated against the rules rather than patched into compliance afterwards. And the finishing pass — alt text, meta descriptions, structured data, the accessibility details that get cut when a deadline tightens — stops being a cost at all.

What AI does not remove

Discovery does not get cheaper. Deciding what the site is for, who it is talking to and what each page has to achieve takes the same conversations it always did. If anything it takes longer now, because production is no longer the bottleneck — the thinking is.

Integrations do not get cheaper either. Payment providers, CRMs, booking systems and anything with a third-party API still need careful, tested work, because the cost of getting them wrong is real money rather than a misaligned margin.

And content does not get cheaper in the way people hope. A model can draft copy quickly, but the facts, the positioning, the proof points and the specifics that make a page persuasive have to come from you. Generated copy with nothing behind it reads exactly like what it is.

The line that gets bigger

Because building is now fast, the temptation is to build more — more pages, more variants, more sections. Every one of those is something to maintain. The ongoing cost of a site is driven by how much of it exists, and AI makes it very easy to accidentally own a great deal more site than you need.

This is where an AI-native build genuinely can go wrong financially. Not in the build, in the second year.

What this means for your budget

• Expect the build line to fall, not the project total. A cheaper build with the same discovery and integrations is a smaller saving than the headlines suggest.
• Budget for content properly. It is now the most likely thing to delay your launch.
• Ask what the site costs to run. A fixed build price attached to an open-ended maintenance story is not a fixed price.
• Be suspicious of scope that expands because it is easy. Fast to build is not the same as free to own.

We quote fixed prices for exactly this reason: the savings should show up on your invoice, not in an agency’s margin, and the number you are given at the start should be the number you pay.

Ask a model to build you a landing page and you will get a landing page. It will have a hero, three feature cards, a testimonial and a call to action. It will be competent, it will be responsive, and it will look like every other page produced the same way that week.

That is not a failure of the tool. It is a failure of the question. The model answered the brief it was given, and the brief was “build me a landing page.” Nobody had decided what the page was for.

The work AI is genuinely good at

We use AI on every build, and it earns its place. It is faster than a human at the parts of web development that are mechanical rather than considered:

• Production. Turning an approved design into clean, responsive markup — the part that used to eat days.
• Consistency. Applying a token change across forty components without missing three of them.
• First drafts. Getting a section from nothing to something you can react to, which is far easier than reacting to a blank page.
• The boring passes. Alt text, meta descriptions, schema markup, responsive edge cases — the work that gets skipped when a deadline tightens.

The work it is not good at

Every one of these requires knowing something the model was never told:

• What the site is actually for. A site that needs to book consultations is a different object from one that needs to reduce support tickets, even when they look identical in a screenshot.
• What to leave out. AI adds. Asked to improve a page, it will give you another section. The best edit on most pages is a deletion, and nothing in the training data rewards that.
• Which objection to answer first. Ordering a page is a sales decision informed by what real prospects hesitate over. That knowledge lives in your inbox, not in a model.
• What it will cost you in two years. A structure that is quick to generate is not always cheap to maintain. Someone has to be accountable for the second year.

What goes wrong without an architect

The failure mode is rarely dramatic. The site launches, it looks fine, and it quietly underperforms. There is no single broken thing to point at — just a page that talks about features when the buyer needed reassurance, a form asking for nine fields when three would do, and a structure nobody can extend without a rebuild.

These are not bugs. No test catches them. They are decisions that were never consciously made, because the tool was happy to make them by default.

How we actually split the work

Humans decide, AI produces, humans verify. The decisions — what the site is for, what each page has to do, what the structure needs to survive — are made before anything gets generated. Production is where the speed comes from. Then every section is checked against the goal it was supposed to serve, not just against whether it renders.

That division is why an AI-native build is faster without being thinner. The hours saved come out of production, not out of thinking.

If you are weighing up an AI-assisted build, the question worth asking any agency is not which models they use. It is who on the team is accountable for the decisions the model cannot make.