You generate a website, change some colours, add your services, and it looks pretty good. Then you get stuck. Something breaks on mobile, the pages feel disconnected, or you cannot get the form working properly.
So you contact a developer: “It is about 90% done. I just need someone to clean it up.”
I understand why it looks that way. You can see the pages. But the amount of website visible on your screen does not tell you how much of the project is finished.
Before treating the remaining work as a small job, someone needs to establish whether what you have is usable for the business, not only whether it looks finished.
A generated version does not establish the project’s value
The Guardian reports an 87% rise in AI-correction listings on Freelancer.com between August 2025 and June 2026.
That covers broader creative work, rather than websites specifically. But the same distinction matters here: generating a draft is not the same as producing work a business can rely on.
AI can produce the first draft quickly. Turning it into something worth using, trusting and paying for still requires human judgment.
With a website, the generated version might help communicate the layout or direction you like. That is useful. But it does not automatically reduce the work required to build something your business can rely on.
If the structure needs replacing, the content needs rewriting and the functionality needs rebuilding, the developer has to do that work regardless of how finished the screenshot looks.
In a case where a large part of the implementation needs rebuilding, “cleanup” is a misleading description. Your AI version is effectively the brief. That is closer to how I would also think about a rough redesign brief than a nearly finished site. See what usually drives website redesign cost.
Why a polished first draft can still be 10% of the project
The “90% done” estimate usually comes from what is visible. If the homepage, service pages and contact page are on screen, it feels as though only the final details remain.
But a generated set of pages can be closer to a 10% first draft when nobody has yet defined the content structure, reusable components, mobile behaviour, enquiry process, search setup, security or maintenance. The design direction may be useful, but the completion percentage needs to be measured against an agreed scope, not the number of screens that have been generated.
The work you cannot see still needs doing
Start with the footer. Do all the links lead somewhere? Is it consistent across the website? Can someone update your contact details once, or has each page been built separately?
Then check the enquiry form. Does the message reach the right person? What happens when submission fails? Is the information useful enough for your team to follow up?
Look at the pages themselves. Do they explain your services accurately? Do they answer the questions customers ask before buying? Can visitors move between services, relevant examples and contact options without getting lost?
These are practical requirements. A nice layout does not resolve them.
The technical setup and commercial direction count too
A business website also needs foundations that a screenshot cannot show. The exact list depends on the project, but I would normally ask:
- SEO and sitemap:Can search engines crawl the important pages, understand their titles and structure, and find them through a useful XML sitemap and internal links?
- Security and recovery:Is the software maintained, is access controlled properly, and can the website be restored from a working backup?
- Performance and caching:Are images handled sensibly, is caching configured for the platform, and does the website remain usable while it loads?
- Brand consistency:Are colours, typography, spacing and interface components applied as a system, or has every page invented its own version?
- Meaningful layouts:Does each layout support the content and decision a visitor needs to make, rather than filling the page with attractive but interchangeable sections?
- Conversion paths:Can someone move from a service to relevant evidence and then to the right enquiry or buying action without guessing what to do next?
If these decisions have not been made, the developer is not quoting to polish the final 10%. They are being asked to establish the missing direction and then build it.
A business website brings together design, development, copywriting, SEO, accessibility, applicable compliance requirements and performance. Those disciplines affect one another. A decision about content changes the layout. A decision about functionality affects maintenance. Your internal process affects how enquiries should be handled.
Break the project into its deliverables and checks, and you can easily reach 50 or more tasks, depending on the scope. Some require substantial decisions before anyone starts building. That is why a small business website budget is rarely just “finish what AI started.”
What I would check before calling it a cleanup
Shared structure
Header, footer and contact details live in one place, not copied page by page.
Working enquiries
Forms deliver usable messages, handle failure, and match how your team follows up.
Clear service paths
Pages answer buying questions and connect services, examples and contact options.
Mobile and basics
Key pages work on a phone, load reasonably, and do not hide broken navigation.
Editable content
Someone who is not the original generator can update services, prices and contact info.
Ownership and hosting
You know where the site lives, who can change it, and what happens after launch.
AI still needs someone who knows what good looks like
AI can execute well-defined tasks quickly. But somebody needs to define them, give it the right context, inspect the result and catch what it missed.
Without that knowledge, you can end up approving shortcuts because you cannot see their consequences yet. The page works today, but adding another service means copying and repairing five different things. A change fixes one screen and breaks another.
You keep prompting because each problem looks fixable. Eventually, you have spent several weekends on a website you still cannot confidently launch or maintain.
An expert brings the judgment to decide how the pieces should fit together, which requirements matter for your business and what needs checking before customers use it. That is a substantial part of what you are paying for, even when AI helps produce the code. The same idea shows up when you hire a web developer without being technical: you are buying judgment and delivery risk management, not only keystrokes.
| Cleanup language makes sense when | Rebuild language fits better when |
|---|---|
| Structure, content model and forms already match the business. | Pages were generated separately and cannot be maintained in one place. |
| Bugs are local: spacing, copy, a broken link, one form field. | Mobile layout, navigation and enquiry flow need rethinking across the site. |
| Someone can explain how updates, hosting and ownership work today. | Nobody is sure what can be changed safely without breaking other pages. |
Bring in expertise before the rebuild becomes necessary
If the website matters to your business, I would involve the right people from the beginning. Establish the structure, content, functionality and maintenance requirements before investing time in generating the whole thing.
You can still bring ideas, references and an AI mockup. Just bring them as a starting point for discussion. Allow the people responsible for delivery to assess what can be reused and what should change.
A developer may reasonably decline a small cleanup budget when the work requires a rebuild. Taking responsibility for an unfamiliar implementation includes investigating it, correcting it and checking that the result works. Existing code can add work as well as save it.
“It is 90% done”
Visible pages are not a completion meter. Usability still has to be checked.
“Just tidy the CSS”
If structure and forms are wrong, styling is not the main job.
“AI already built it”
A draft can communicate direction without reducing delivery scope.
“We can fix it as we go”
Repeated prompts without a plan often create more fragile pages.
The project’s value should reflect what your business needs delivered. A rough version you cannot improve yourself does not establish a lower price for achieving that outcome.
Final takeaway
An AI-generated website can be a useful starting point. It is not proof that the hard part is finished.
Before treating the remaining work as a small job, someone needs to establish whether what you have is usable for the business, not only whether it looks finished.
If you already have an AI-generated website, send it over with what you need it to do. I can assess what is usable, explain what needs rebuilding and scope the work around a website your business can actually use.
Frequently asked questions
Is an AI-generated website usually close to launch-ready?
Sometimes parts of it are usable. Often the visible layout is ahead of the structure, forms, content and maintenance path. Treat it as a draft until those are checked.
Why do developers push back on a small cleanup budget?
Because taking responsibility for the site means investigating it, fixing what fails and checking the result. If large parts need rebuilding, the cleanup label understates the work.
Can parts of an AI website still be reused?
Yes. Direction, layout ideas, wording and some components can survive. Reuse should follow an assessment of what is solid, not an assumption that most of the build is finished.
What should I send when I ask for an assessment?
The live URL or export, what the website needs to do for the business, who handles enquiries, and any known problems such as forms, mobile layout or missing pages.
Should I keep prompting until it feels finished?
Only if you can define the next requirement and verify the result. Without that, weekends of prompts often create more fragile pages instead of a site you can maintain.
