I run SharpHaw, a small digital agency, so I have an obvious professional interest in how businesses judge website work.
AI website builders are now good enough to make a convincing marketing site quickly. I do not think arguing about whether they can “build a real website” is useful anymore. For many straightforward sites, they clearly can.
The harder question is what the business owns six months later.
I have started using a deliberately boring test: ask somebody who did not build the site to change one price. They should be able to find the source of truth, preview the edit, publish it and reverse it without the original builder guiding them or reopening a long prompt history.
Then I submit the contact form and trace the enquiry. I want to know where validation happens, where the data is stored, who gets notified and what the user sees if delivery fails. A success message on the page is not evidence that the lead reached anyone.
The same goes for analytics. I want one test action to match one accepted business outcome and one recorded conversion. If the button click is recorded but the form was rejected, the dashboard is telling a nicer story than the system.
Search access is another quiet dependency. The business should own the domain and DNS, control its Search Console property, know where the sitemap comes from and be able to inspect a changed page. “The site is indexed” is not enough if only the original builder can investigate when it stops being indexed.
Recovery is where the answers get vague. “The platform has backups” sounds reassuring, but I want to see somebody identify a known-good release and restore it in a safe environment. The source, content and dynamic data may have different recovery paths.
Export claims need the same treatment. Getting HTML, CSS and assets is useful. It may not include structured content, form processing, customer data, accounts, search, localisation, commerce, environment settings or deployment history. That does not make a managed platform bad. It means “we can export the code” is not the end of the inventory.
The final test is a handover to another competent operator. Give them the repository, access map, content source, environment inventory, deployment notes, recovery path and list of external services. Ask them to run the site, make one change, trace one lead and explain a rollback.
They do not have to like the stack. They should be able to understand it.
There is a real trade-off here. Doing all of this on a throwaway landing page would be overkill. Managed platforms are often worth depending on because they remove maintenance work. The goal is not zero dependencies. It is to make each dependency visible, owned and replaceable at a cost the business understands.
My shortest version is the cancellation-day question: if the builder, platform or subscription disappeared today, what would still work tomorrow?
What would you add to the six-month test based on a site you had to maintain or inherit?
TL,DR: AI builders have mostly passed the launch test. I judge the result by whether a non-builder can edit it, a lead can be traced, access is business-owned, a release can be restored, the full system can move and another operator can take over.
Source: r/SharpHaw · by /u/SharpHaw