The list nobody prompted for
**Weight.** Generated builds ship every library they touched and every image at full size. It feels instant on a desktop with fibre and takes six seconds on a phone in a car park, which is where the visit actually happens.
**Structure.** Headings that describe the page rather than decorate it, one h1, alt text, a title and description per page. None of it is visible, all of it decides whether the page is findable.
**Forms that arrive.** Not submit — arrive, in an inbox a human opens, with a confirmation the sender can see. A form that silently fails looks identical to one that works, and it is the most expensive bug in this business.
**Analytics before launch, not after.** Otherwise the first month has no baseline and every later argument about performance is a matter of opinion.
**Redirects.** If anything existed at these URLs before, the map is the whole job, and doing it after the switch is doing it too late.
**Editing.** Who changes a headline in March, and can they do it without a developer? If nobody can, the site is frozen from the day it ships.
Why the last ten percent is most of the work
Every item above is invisible in the browser. The prototype looks done because looking done is what a prototype is for, and the parts that remain are the parts nobody can see.
They are also the parts that decide whether the site earns anything: whether it loads before people leave, whether search can read it, whether enquiries reach you, whether you can tell. The visible layer was the cheap half all along.
This is why *we are ninety percent there* is the most misleading sentence in software. The remaining ten percent is where every project's schedule goes to die, with or without AI.
The cheapest way through it
Keep the prototype as a design artefact rather than a foundation. It has settled the layout, the copy and the structure, which is genuinely most of the thinking, and it cost you a day.
Then build the live version properly on top of those decisions. In our experience that takes about three weeks for a marketing site, and the prototype makes those three weeks calmer because nothing is being invented mid-build.
The alternative, hardening generated code you never read, is occasionally right and usually slower, because you spend the time understanding somebody else's decisions instead of making your own.
A site where the invisible half was the brief
i4B builds software for electric-vehicle manufacturers, across ten pages, with case studies and careers on a CMS their own team updates.
Nothing about that is visually complicated. All of it is structurally specific: what lives in a collection, what a non-technical editor touches, how a new sector page appears without a developer.
A model can render any one of those pages. Deciding which of them should exist, and who owns them afterwards, is the part that took the meeting.
Questions we get asked
What is missing from an AI-generated website before it can go live?
Usually six things: page weight and speed on real phones, heading and metadata structure, forms that deliver to a real inbox, analytics installed before launch, a redirect map for existing URLs, and a way for a non-technical person to edit the content.
Should I rebuild an AI prototype or fix it?
Fix it when the structure is sound and the problems are surface-level. Rebuild when the page structure, the CMS model or the URL scheme are wrong, because those are foundations and patching them costs more than pouring them again.
How long does it take to take an AI prototype to production?
For a marketing site, about three weeks with the prototype as the starting point, because the layout and copy arguments are already settled. The variable is not the code; it is how much content and how many integrations are involved.