Save good work, retry the failed step, and inspect the page

A finished marketing website depends on several different kinds of work. The system must understand the brief, gather product evidence, choose a structure, write claims, select assets, compose sections, produce code, load the page, and inspect what visitors see. Each stage can succeed while the next one fails. Strong copy can land in the wrong hierarchy. Correct code can render an unreadable hero. A good desktop page can collapse on a phone. Treating the whole job as one model response hides those boundaries. An AI website workflow becomes dependable when each stage has a clear input, a visible output, and a rule for what happens when that output is not usable.

Save the last version you know is correct. Approve the page job before producing a detailed layout. Approve the section order before polishing ten blocks of copy. Confirm which claims have a source before making them prominent. Confirm that you may use an image before composing a hero around it. These pauses do not need a meeting or a separate report. A concise preview and a clear choice are enough. If the section order changes after responsive styling, you must repair the copy, layout, and phone view. If it changes while it is still an outline, you move a few lines and continue from a known-good version.

When one stage fails, restart from the last trustworthy checkpoint. If an image cannot be cropped without hiding the product, choose or generate a better asset; do not rewrite the positioning. If the phone hero overflows, repair its content fit and responsive rules; do not regenerate the desktop page. If a provider request times out, retry that request with the same approved inputs rather than asking a fresh model to reinterpret the entire job. Local retries preserve progress and produce useful evidence. They also make quality improve over time because the workflow can identify recurring failure classes instead of treating every bad result as a mysterious full-page disappointment.

Website work rarely finishes in one sitting. A founder may approve the section order, wait two days for screenshots, then return with revised pricing. Keep the approved brief, current page, selected assets, and open questions in files the next session can read. A chat transcript is a poor substitute because it mixes current instructions with discarded ideas and casual discussion. When work resumes, open those files, identify the next unresolved decision, and continue from the last saved version. The founder should not have to reconstruct yesterday's choices from memory.

Some gaps should produce a pause rather than confident filler. A workflow cannot create a real customer quote, verified performance number, supported integration, or legal promise from design intuition. It can still make progress by choosing a structure that does not depend on the missing claim, using a clearly marked draft, or asking for one concrete fact at the point it becomes necessary. This is different from stopping at every uncertainty. The workflow should continue through reversible design choices and pause only where invention would alter the business truth. A useful pause explains what is missing, where it will appear, what alternatives exist, and which option the agent recommends.

Code checks catch syntax and dependency failures. They do not prove that a person can understand or use the page. Open the route a visitor will receive after fonts, images, and layout have settled. Inspect the first screen, the transition between sections, content density, image fit, contrast, repeated ideas, and the final action. Look for contradictions as well as breakage. A heading about team collaboration beside an unrelated analytics screenshot is technically valid and still wrong. Compare the rendered page with the brief, name the visible defect, change only the rule or component that caused it, then reopen the same route and check the correction.

Responsive design is not a scaled-down desktop screenshot. At phone width, navigation changes, headings wrap, columns reorder, screenshots crop, customer evidence may move below the first screen, and tap targets become the main interaction. A desktop pass cannot stand in for a phone review. Check both views from the same current page so the copy and open controls are identical. Record the full phone viewport, such as 390 × 844 px, the browser or device, 100% zoom, page state, and capture date. Inspect the full page and pay special attention to the first action, forms, pricing, long words, and horizontal overflow. If you test only a width, describe the order of content instead of claiming what appeared before scrolling.

Observability for website creation should answer practical questions. Which brief version produced this page? What structure was approved? Which copy and assets did the system receive? What step failed? What was retried? What changed between the last good render and this one? You do not need an unreadable log of every token. Keep the decision inputs, material outputs, warnings, and transitions that help a person diagnose the result. This history protects against two common mistakes: blaming the model when the input was wrong, and adjusting prompts when a deterministic layout or asset problem caused the defect. A visible chain turns taste arguments into inspectable work.

“Generation completed” only means the process stopped. A stronger definition of done describes the outcome: required routes load, the page communicates the intended job, claims match supplied facts, assets fit their sections, links and forms work, approved content remains intact, and desktop and mobile views have fresh visual evidence. Publishing may be a separate approval boundary, but the candidate should be ready for that decision. This definition prevents an empty render, placeholder-heavy layout, or technically valid draft from being presented as success. It also gives retries a target. The workflow continues until the website is usable or a named missing input makes honest completion impossible.

Keep one short list beside the website: the current brief, approved section order, sourced copy, selected assets, latest desktop render, latest phone render, and publication decision. For each item, name the owner and the next unresolved question. If the phone review fails, reopen the same page with the same copy and assets and repair the phone layout. If a product fact changes, revisit only the sentences and sections that use it. This list earns its place when it lets you recover a good version and continue without rebuilding the whole site.