Buying an AI Website Tool Does Not Replace Expertise, Whatever They Tell You

Business owners, startup founders, entrepreneurs: please stop and think.

Just because you can purchase a tool that generates a website does not mean you have purchased the knowledge required to build one properly. You have acquired the ability to produce something. Knowing whether that something is suitable for your business still requires expertise.

I use AI extensively in development. I know how much faster it makes the work. I also know how confidently it can build something that makes absolutely no sense when nobody with experience is directing it.

I have dealt with exactly that.

Buying the ability to generate a website is not the same as knowing whether that website is suitable for your business.

Frontier AI built a website that made no technical sense

I had a case where a client used ChatGPT and Claude Code to generate standalone HTML files, uploaded those files to external hosting, and embedded them into Wix pages through iframes.

Wix provided the outer website. The actual page content lived inside separate HTML documents displayed within it.

Those documents contained almost everything inline: CSS, JavaScript, SVG graphics, even photographs encoded as base64 text directly inside the HTML. Individual documents had grown to multiple megabytes, with some reaching tens of megabytes.

This was ordinary website content, packaged in a way that made the browser do unnecessary work just to display it.

The workflow was then repeated across more pages. Each new file added another separate implementation to maintain, another place for styles to drift, another opportunity for navigation and content to become disconnected.

Somebody used a frontier AI coding tool to produce an architecture I would challenge immediately in a normal development review.

That is the part people need to understand. Access to a capable model did not prevent a fundamentally poor implementation. The model generated what the workflow encouraged, and nobody stopped the process early enough to question whether the workflow itself made sense.

The website paid the penalty through slow loading, difficult maintenance, and an unnecessarily complicated foundation for search visibility.

Looking finished is a dangerously low standard

If you opened one of those pages and waited, you could see a designed layout. There were images, text, buttons, and sections.

To somebody evaluating the appearance, that might look like a completed website.

The browser still had to download and process the oversized document. Repeated resources were bundled into individual pages instead of being managed as shared assets. Changes that should have been straightforward became work across separate files.

Inlining itself is not automatically wrong. A small SVG or some critical CSS can make perfect sense. Packing photographs and an entire page’s resources into a huge HTML document prevents those resources from being cached independently and reused across pages in the normal way. Even an image marked for lazy loading still contributes to the HTML download if its data is embedded in that document. Google’s image performance guidance explains those tradeoffs.

An experienced developer understands when an exception is useful and when somebody has turned that exception into the architecture of the whole website.

Without that knowledge, “it works” can mean nothing more than “something eventually appeared on my screen.”

That is not enough for a business website. I wrote about the same gap from the other side in Your AI website looks almost finished: visible pages are not a completion meter.

More pages do not automatically mean better SEO

Another part of the thinking behind this approach was that having more pages would improve search visibility.

So considerable effort went into producing more individual pages before the underlying structure had been properly resolved.

A page count is not an SEO strategy. Neither is a large sitemap.

A sitemap helps search engines discover URLs. It does not guarantee that those URLs will be crawled, indexed, or ranked. Google says so in its sitemap documentation.

You still need useful content, sensible navigation, appropriate internal links, and a clear relationship between the public URL and the content you want indexed.

An iframe does not automatically make content invisible to Google. Loading the main content from a separate document still introduces questions that need to be understood and checked. Google’s documentation on embedded indexing makes those considerations explicit.

You cannot generate your way around those decisions.

And when I say a website pays a penalty for poor implementation, I mean it suffers the consequences. A formal Google penalty is a separate claim that requires evidence. The technical problems are serious enough without inventing one.

Buying bricks does not make you a builder

I can buy concrete, a shovel, and a pallet of bricks.

Nobody at the checkout will ask whether I understand foundations, structural loads, drainage, or how a building behaves after several winters. The tools and materials are available. My arms are physically capable of moving them.

That does not mean I should build a commercial building.

Could I build a small shed as a learning project? Probably, with enough preparation, time, and willingness to correct mistakes. That is a perfectly reasonable way to start.

Could I learn how to build something much more demanding? Yes. Expertise is learned.

It takes time. At some point I either develop the necessary competence, involve experienced people, or proceed without understanding the consequences.

The same applies to websites and software.

Build your personal page. Experiment with an idea. Make a prototype. Use AI to help you learn.

If you have no development experience and no willingness to spend months learning the foundations, followed by years developing deeper judgment, stop assuming a few prompts will give you the same result as somebody who has done that work.

There is no magic six-month qualification, either. The learning required depends on what you are trying to build and how much responsibility it carries.

Your willingness to click “generate” does not change that responsibility.

I would not build your business website while grilling

I keep seeing versions of the same promise: build an entire business website in an afternoon, casually, from your phone.

Could I generate something that looks like a website in three hours? Yes. Other experienced developers could too.

I would not stand in the garden, turn the food on the grill, send a few prompts between messages, and then tell a paying client that I had properly considered their business and delivered the right solution.

I take the work more seriously than that.

The first three hours could easily go into understanding your company, your market, your audience, what you sell, what customers need to know, how the content will be managed, and which technology makes sense for the project.

Those decisions determine what we should build. They also change what a small business website actually costs.

Generating a polished layout before answering those questions can create the appearance of progress while committing you to the wrong solution.

An experienced developer’s speed comes partly from knowing which decisions matter and which approaches to avoid. You do not acquire that judgment by using the same tool.

We use AI. We also know when it is doing something stupid

When I use an agent, I need to understand what it is changing and why.

I need to recognize when it drifts away from the requirements, duplicates something we already built, adds unnecessary dependencies, or solves the visible symptom while leaving the underlying problem.

I need to know when the output is acceptable, when it needs correction, and when we should throw it away.

That also means noticing what is missing.

Understand the change

I need to know what the agent edited and why that edit belongs in the project.

Catch drift

Duplicated pages, extra dependencies, and solutions that only treat the symptom still have to be spotted.

Notice what is missing

Broken form delivery, inaccessible navigation, and a maintenance process nobody can use will not announce themselves.

Throw work away

A convincing interface is not a reason to keep a bad implementation. Some output should be discarded.

A convincing interface can hide broken form delivery, inaccessible navigation, inconsistent content, poor error handling, or a maintenance process that nobody in the company can use.

If you do not know those things should exist, you may never ask the agent to address them. That is also why hiring a web developer is often a judgment purchase, not a typing purchase.

Giving it more context does not automatically solve that. Two hundred thousand tokens, a million tokens, whatever comes next: the capacity to receive information is not a guarantee that every relevant decision will be applied consistently.

Humans forget things too. That is why we document decisions, review changes, test behavior, and maintain a project history.

When the agent’s conversation resets, my responsibility for the project does not reset with it. I still need to understand what we are building.

The human mind is not obsolete

I am also tired of how casually people treat the replacement of human expertise as a problem that has already been solved.

AI operates on physical hardware. That hardware needs electricity, memory, cooling, manufacturing, and infrastructure. We do not have unlimited compute running on almost free power.

These are real constraints. The International Energy Agency identifies energy supply and grid capacity as significant issues for expanding AI infrastructure. Its Energy and AI report explains those limitations.

Better models and more efficient software matter. Hardware and infrastructure matter too. None of those improvements, by themselves, establish that reliable judgment across an entire business project has been solved.

Meanwhile, look at the system we are so eager to declare obsolete.

A person can eat a decent meal and spend an afternoon working through a difficult problem, drawing on experience, connecting ideas, and making creative decisions while their body continues breathing, blinking, balancing, and moving.

I find that extraordinary.

Our minds are imperfect. We forget, get tired, and cannot process enormous datasets the way machines can. The biological system that supports our thinking has developed over millions of years. Dismissing it because a model can produce a large quantity of plausible output strikes me as a very shallow understanding of intelligence.

The meal comparison is not a scientific benchmark, and I cannot tell you what AI will eventually become. I would certainly not run a business on the assumption that human expertise is already unnecessary.

Digital complexity is still complexity

Most people understand that owning a scalpel does not qualify them to perform surgery. They can also look at a commercial construction site and recognize that considerable expertise is involved.

The physical consequences are visible enough to make them pause.

A website hides most of its complexity behind a screen. You see a section, an image, some text, and a button. You do not immediately see the data flows, dependencies, accessibility requirements, failure conditions, or decisions required to keep it working.

That makes it easier to underestimate.

You discover the missing expertise later, when enquiries fail to arrive, an update breaks several pages, customers cannot complete an action, or a simple content change requires somebody to untangle the implementation.

The complexity was there before the failure made it visible.

AI vibe-bro lies induced this client insanity

That website did not stay a technical curiosity. After I had already written down what was wrong and what it would take to fix it, I had a follow-up meeting with the same company.

They had hired me to audit the workflow, name the performance, SEO and maintenance problems, recommend a target architecture, and pilot a better path. The job even framed it as optimization and a possible Wix replacement. They were not a technical team. They did not understand web development. That is fine. That is why you hire somebody who does.

What they wanted on the call was something else. They wanted to stay on Wix. Their public site does not actually use Wix as a website builder. Wix is a shell with a domain pointed at it. Almost every designed page is an iframe loading a separate HTML file from another server. ChatGPT and Claude Code generated those files. Photographs sit inside the HTML as base64 text. Around 140 editor pages. Across the designed set, about 20 repeating components, written again on every page instead of defined once.

I told them the honest rebuild is WordPress, with those components as real instances. Recreating the AI-generated UI inside Wix is close to impossible. They did not want to hear it, because there are a lot of pages. They treated page count as a reason to keep a broken method, not as a reason to stop duplicating it.

They asked me to optimize the iframes. I said I can extract the photographs, store them as files next to the HTML, and the iframe will load a bit better. It will not be fast. Every visit is still a two-hop trip: the domain hits Wix, then Wix loads remote HTML. You cannot apply a real caching policy to that. Google does not treat that iframe as first-class content of the domain. It indexes an embedded external resource as what it is. Wix has no advanced caching that would save this, and even if it did, you cannot cache an iframe, or images that are not files.

They refused the proper solution. Then one of them asked how I could improve the workflow so the client could generate more pages with AI, but not as HTML, because they do not want HTML pages. There is no page without HTML. One of them thought the problem was the file format.

I said after a rebuild they could connect to the site through Skylit.DEV (opens in a new tab), the framework I already use for that, so an editor can make smaller changes with AI without owning the whole architecture. They did not want a rebuild. They wanted to stay in Wix. I offered Cursor on the server over SSH, with a skill that stops the agent from doing the next fatal thing. An agent will eventually do what you asked. One of them had seen Visual Studio Code before and was afraid of the complexity.

Then came the question of how they can keep developing the website themselves through ChatGPT and still make sure everything is good. I said it is possible if they invest the time to learn basic to intermediate web design and development. You cannot be a developer without learning development. They do not want a CMS. They do not want an IDE. They do not want to learn. They want to develop pages with AI because they saw it somewhere: YouTube, Facebook, a demo that skipped the part where somebody still has to understand the result.

I have a lot of patience. It has an end. I told them they can pay me, or another developer, to untangle a 140-page mess and put a workflow on a track that is actually web development. That work is not cheap. They can hire somebody in-house. Or they can keep listening to dishonest AI vibe bros, pay for two frontier models on max plans, and spend days generating pages while the business pays for the hallucination.

They were offended. The meeting ended quickly. Then they disclosed that this was not one website. They have many more like it on Wix, under different domains. Same iframe shell. Same generated HTML. Same refusal to change the method. I would not take a project like that under a six-figure engagement. I already know the pain. I am not willing to sit inside that madness for a discount.

You cannot skip HTML, skip the CMS, skip the editor, skip learning, and still “make sure everything is good.”

Stop selling expertise you do not provide

To the AI SaaS companies and startups marketing these tools: please stop promising that anybody can do everything.

If a demonstration leaves out the work needed to make the result dependable, say so. If customers need technical knowledge to evaluate the output, say so. If a growing project will require experienced help, say so.

Stop hiding those facts to secure another monthly subscription.

When you knowingly imply that your tool removes the need for expertise while leaving the customer to discover that expertise is still essential, that is dishonest.

The customer pays for the tool, invests time building on the promise, and then pays again to repair or replace what they thought was finished.

These tools are useful enough to sell honestly. You do not need to pretend that a successful demonstration makes the user competent in an unfamiliar profession.

Business owners need to meet that honesty with some seriousness of their own.

Before you generate another page, establish who understands the implementation, who can evaluate it, and who will take responsibility when it fails.

If you want to learn, learn. If you want to experiment, experiment. If your business needs dependable professional work, involve somebody qualified to judge it.

Final takeaway

This is for business owners, entrepreneurs, and anybody else who needs a website that actually brings in business.

If you are not a technical person, and you are not willing to become one, stop this madness.

While you burn money through tokens and spend days building something that will not help you get more business, and may actually cause the business to fail, your successful competitors are doing something else. They hire developers to do the work properly, and they pay for it.

They do not undervalue that work because developers can now move faster. They value it more. Faster means better, more complex solutions in less time. It does not mean cheaper.

The real benefit is a project that used to take six months arriving in one or two. Traffic, clients, and the return from a properly built website show up sooner.

So yes: while you waste time and money on something that will never pay off, your competitors are focusing on their businesses. They paid developers to do the job right. They are ranking. They are being referred and cited in AI models. They are getting clients. Your potential business. While you play the “I do not need a developer” slot machine.

Buying the ability to generate a website is not the same as knowing whether that website is suitable for your business.

If you already have a generated website and you are not sure whether the implementation will hold, send me the URL and what the site needs to do. I can tell you whether you have a prototype, a problem, or something your business can actually run.

Frequently asked questions