Skip to content
Adamarant
Start
Web

AI website builder problems: the 5 limits that stop scaling

An AI builder ships a site in a day. Five limits stop it growing: duplicated code, open databases, invisible pages, a locked stack and agents in production.

October 29, 2026 · 10 min read

A staircase of white tiles climbs from the bottom left in five steps until it meets a ceiling of five white slabs across the top; to the right the columns stop at the same height and turn dark, forming a flat plateau under the ceiling

A site built with an AI builder works on the first day. The trouble starts around the tenth change: a new feature breaks two old ones, a page that loaded in a second now takes four, and nobody can say which database rows a logged-out visitor can read. These are the AI website builder problems that show up once a site has real users, and they share one cause. The builder wrote each part of the code to answer one prompt, and nobody wrote the plan that holds the parts together.

An AI website builder is a tool that turns a written prompt into a working site or web app, code and hosting included. The category covers the prompt-to-app products and the AI modes that classic site builders now ship. For a first version they are fast and often good enough. This article covers what comes after: the five limits that stop an AI-built site from scaling, what each one costs, and how to repair a site that has already hit them.

What does it look like when an AI-built site stops scaling?

The signs are easy to recognise once you know them:

  • Every prompt fixes one thing and breaks another, so each change takes longer than the one before.
  • The same logic lives in three or four files, each version slightly different.
  • Pages appear on Google but never in ChatGPT or Claude answers.
  • Nobody on the team can say who is allowed to read which table.
  • The code sits on the builder's servers, and leaving would mean starting over.

One of these is a bug. Three of them together mean the site has reached the size where prompting alone no longer holds it.

Why does a site built with AI stop scaling?

A prompt is a local request. The model reads part of the project, writes the shortest change that satisfies the request, and moves on. Adding a new block is cheaper for it than reorganising three old ones, so the code grows by addition. Refactoring, the work of moving code so it can be reused, needs someone who knows the whole system and wants it to stay small.

The trend is measurable even where a developer is in the loop. GitClear's 2025 study of 211 million changed lines found that in 2024, for the first time, more code was copied and pasted than moved, and blocks of five or more duplicated lines grew eightfold during the year. That data comes from teams using AI coding assistants with engineers reviewing the result. In a builder driven only by prompts, nobody is assigned to do the moving.

The 5 limits that stop an AI-built site from scaling

1. Code that grows by copying

Duplicated logic works until it has to change. A pricing rule written in four places gets updated in three, and the fourth keeps charging the old price. Each new feature adds surface for this kind of drift, so the cost of a change rises with the size of the codebase rather than with the size of the change. This is the first limit a growing site hits, and the one that makes every later fix slower.

2. Security defaults nobody checked

A generated app that stores user data needs access rules on every table. When the rules are missing, the public key shipped to every browser is enough to read the data. That is what CVE-2025-48757 describes: an insufficient Row Level Security policy in sites generated by one of the most used AI app builders, through 15 April 2025, let unauthenticated attackers read or write arbitrary tables. The NVD rates it 9.3, critical, and records that the vendor disputes it. Researchers found more than 170 exposed apps, with names, addresses, debt amounts and API keys among the data.

The pattern is wider than one platform. Veracode's 2025 GenAI Code Security Report gave 80 coding tasks to more than 100 language models and found that 45% of the results introduced a vulnerability from the OWASP Top 10, with cross-site scripting left open in 86% of the relevant tasks. A site can pass every manual test and still hand its database to anyone who opens the browser console. Access rules are design work, covered in our piece on Supabase Row Level Security at scale.

3. Pages that search engines and AI crawlers cannot read

Many AI-built sites render in the browser: the server sends an almost empty HTML shell and JavaScript fills it in. Google can render JavaScript, though it queues pages for rendering as an extra step after crawling. AI crawlers mostly cannot. A study by Vercel and MERJ found that none of the major AI crawlers execute JavaScript, including OpenAI's GPTBot and OAI-SearchBot, Anthropic's ClaudeBot and PerplexityBot. A page that exists only after JavaScript runs is a page those engines never see.

Builders are responding. The most used one switched new apps to server rendering on 13 May 2026, and serves pre-rendered copies of older apps to verified crawlers. Projects created before that date, and sites on builders that never changed, still render in the browser. The test takes a minute: request the page with curl and check whether the text a reader sees is in the HTML that comes back. Our guide on getting a site into Google and AI search covers the rest.

4. A stack you cannot choose and code that lives on someone else's platform

An AI builder picks the framework, the database and the hosting, and keeps them. One builder's own documentation answers "Can I choose a different framework, such as Next.js?" with "No", and its Git sync creates a new repository rather than connecting an existing one. That is a reasonable product decision for the builder. For a company it means the architecture is set by a vendor's roadmap, and every limit of that stack becomes a limit of the business.

The platform also holds the code, the prompts and the credentials. In April 2026 a researcher disclosed that the same builder's API let any signed-in user read the source code, database credentials and AI chat histories of other users' public projects. The builder removed public project visibility afterwards. A company with its code in its own repository and its secrets in its own vault would have had less on the table.

5. An agent with the keys to production

Builders that run an agent against a live database give it the power to change real data. In July 2025, during a public 12-day experiment, an AI coding agent on a hosted builder ran destructive commands against a production database during a declared code freeze, wiping records for more than 1,200 executives and 1,190 companies. The agent first reported that a rollback was not possible; the data was recovered by hand. The fix is ordinary engineering: separate development and production databases, backups with a tested restore, and no write access to production for anything that has not been reviewed.

What do these limits cost a business?

The costs arrive in different currencies. Duplicated code costs time: each change touches more files, and every release carries more risk of breaking something that worked. Missing access rules cost money and trust: under the GDPR a personal data breach has to be reported to the supervisory authority within 72 hours of becoming aware of it. Client-side rendering costs reach: pages that AI engines cannot read are never cited in their answers. Lock-in costs options: when the stack stops fitting, the only exit is a rebuild.

None of these costs appear on the builder's invoice, which is why the first version looks cheaper than it is. Speed problems follow the same pattern, as we cover in why a website is slow, and so does the slow decay we describe in post-launch rot.

How do you fix an AI-built site that has already hit the wall?

The order matters. Data first, then visibility, then structure.

  1. Get the code into a repository you control. Export it, run it once outside the builder, and write down every secret it needs. If it does not run outside the platform, that is the first finding.
  2. Audit data access. List every table, confirm Row Level Security is on, read each policy, and try to read and write with the public key as a logged-out user. Rotate any key that ever appeared in client code.
  3. Check what crawlers receive. Request your main pages without JavaScript. If the content is missing, move those pages to server rendering or static generation; the logged-in app can stay as it is.
  4. Map the duplication. Find the business rules that exist in more than one place, such as pricing, permissions and validation. Write tests around them, then merge each one into a single module.
  5. Take production away from the agent. Create a separate development database, schedule backups, test a restore, and route every change through review before it reaches production.

After these five steps the honest question is fix or rebuild. If the data model is sound and the duplication sits in a few modules, fixing is the faster path. If every feature depends on copied logic and the data model has no clear ownership rules, rebuilding the core on a stack you choose costs less than patching it for another year.

How do you keep the next AI-built site from stalling?

Use the builder for the work it does well: prototypes, landing pages, internal tools that hold no sensitive data, and the first version of an idea you want to test with real users. Decide the data model and the access rules yourself before the first prompt, since they are the hardest things to change later. Keep the code in your own repository from the first day. And give one person the job of owning the architecture: someone who reads every change that touches authentication, data or payments, and who is allowed to say that a feature waits until the structure can carry it.

An AI builder is a fast way to reach a first version. Scaling past it is the same engineering work it has always been, done on a codebase that grew faster than anyone planned.

Sources

Frequently asked questions

Related services

Next.js

Full-stack development

Related articles

Studio

Start a project.

We write about what we build. Tell us what you want to build.

Talk to the studioRead more articles