I built an AI website builder for Webround. Then I killed it.

Since the early days of building Webround, I always imagined that at some point I would integrate an AI assistant capable of building an entire site from scratch, from a single prompt. Many companies today run marketing specifically around this kind of natively integrated feature, so the desire to introduce something similar in Webround kept growing.

I took advantage of the quieter summer weeks to build an AI builder that, in the end, I didn't release and decided to put on hold.

There was no unsolvable problem behind this decision. But, as I used the builder, some fundamental issues kept surfacing that made me question the entire integration. Webround is a headless platform with public APIs and a full React environment, so anyone can open Claude or ChatGPT, describe what they want, and get working code without me adding anything.

And since the integration was built on the same mainstream LLMs everyone already uses, the question became obvious: why use a proprietary integration that costs more when you can just use your own chat?

How it worked

Webround supports both a visual no-code editor for people who do not write code and a full React environment with Tailwind v4 and NPM support.

The idea behind the builder was simple but ambitious: build an AI service that analyzed the user's request and autonomously decided what to do, how to combine no-code and React, and how to use the wr prop of React components in Webround.

Worried about building an integration with a massive context, I decided to split the planning phase from the execution phase.

A first prompt collected all the data and requirements (copy, structure, color palette, what to change, what to add) and generated a multi-step flow to execute.

A second prompt received each step separately with the operations clearly defined. With strong typing and the right context files, the AI knew exactly what to do to apply each change in the Webround editor.

This approach gave me, in theory, two advantages: the user approves changes before the AI starts working, and each step was isolated and bound to a single prompt at a time, so the AI never ended up with a massive context trying to do everything at once. The results, though, were not what I expected.

No-code generation with AI produces mediocre results

Webround's no-code components are simple, typed, rigid structures. An image component takes a URL, an alt text, and some style properties. In practice, a component is generic React code that knows how to interpret the JSON tied to its configuration.

While it is nothing extremely complex, it still is not free-form HTML generation: the model has to produce output that respects the structure, otherwise every error translates into a missing style or a component that fails to load.

Through the UI this never happens because the user is constrained to editing interfaces that prevent mistakes: you cannot insert a number where a string is expected because the interface simply does not let you do so.

To make the AI understand all of this, you have to inject the entire component type system into the context, otherwise the model would just guess. In most cases the AI did not produce invalid output, and it was not a major problem when it did because I had built a validation system that discarded the output if the model did not respect the expected JSON schema.

The real problem was the visual quality of what got built. It was rarely acceptable because I kept ending up with layouts that made little sense, missed multi-device configurations, and styles that were visually ineffective. It was as if the AI was dropping pieces along the way.

So I started relying more heavily on generating sections entirely in custom React code.

A completely different story with React

When I told the AI to write React code, I realized how capable current models actually are at frontend development. Some of the output genuinely surprised me: beautiful landing pages, balanced colors, fonts, and copy coherent with the site's goal. We all know there is a difference between generating a nice landing page and building a solid frontend, but it was clear that site generation with React code worked well.

It is a task the AI has been trained on extensively, and I got exactly what I expected: correct components, good visual output, correct configurations. I had some occasional issues with unexpected characters breaking JSON formatting in the output validator, but those were identifiable and fixable problems.

At that point I thought the model was limiting the no-code section generation.

The models I used and the cost problem

For this integration I used two models: Gemini 3.5 Flash and Gemini 3.1 Pro Preview. I would have liked to integrate Claude, but I already had a complete Gemini integration ready and decided to reuse it. Honestly, the quality difference was barely noticeable: Gemini 3.5 Flash cost less than Gemini 3.1 Pro and performed just as well.

But, as I kept using the builder, two problems became hard to ignore.

First, output costs were high and I could not simplify them: the planning phase was cheap, but the actual code generation was a real issue. In most cases I was dealing with costs that made the whole thing extremely inefficient. Generating an entire site, which still produced output that required a significant amount of cleanup afterwards, would easily consume one or two euros in Gemini 3.5 Flash credits, depending on the level of detail in the prompt. Factor in the re-iteration a user would need to get exactly what they wanted and those costs could easily double.

Second, no-code generation was unsatisfying and highly inconsistent. Sometimes no-code sections came out well, other times they did not. The more reliable strategy was to rely on React, which is also more flexible and powerful. But then the question becomes obvious: why would anyone use a tool built into Webround, at a premium cost, to generate React code that Claude can generate perfectly well with a bit of Webround context provided?

The further I went, the clearer it became that I was building a system that, using the same models, would cost more and produce results roughly equivalent to what the user can already do on their own. Anyone using a website builder, even if they cannot code, probably already has access to Claude, Gemini, or ChatGPT. If no-code is unreliable and React is the sensible path, why not just give them the right context files and get out of the way?

I was building an AI website builder integrated into Webround that cost more to produce results equal to or worse than what users could get themselves. Not only is that indefensible as a product position, but it also meant maintaining an integration that adds to technical debt without adding real value.

I did not want to walk away empty-handed, though.

What I did instead

Without overthinking it, my questions had clear answers:

Does it cost more? Yes.
Is it better? Not necessarily.
Is it essential? No.
Can it be built later, or differently, from outside? Yes.

So the decision was straightforward: suspend the AI builder, but run one test with Claude.

I created a project, loaded a few context files, gave it clear instructions, and tried building something.

It went exactly as expected. Claude generates clean, good-looking, correct, working React code at a fraction of what it would cost making individual API calls to Gemini, Claude, or OpenAI.

So I wrote three Markdown files designed exactly for this purpose. They contain the information needed to point an AI in the right direction, prevent common mistakes, direct it to the official documentation, and explain the small details of the Webround ecosystem.

webround.md covers the core platform concepts: the difference between draft and store, the runtime architecture, and all the extensibility tools, Checkout Hooks, Edge Hooks, Webhooks and App Extensions, with a clear description of what each one does and when to use it.
webround-apis.md covers the four Webround API systems, Core, Commerce, Catalog and Checkout, with the authentication methods supported by each, the differences between JWT and API key authentication, specific use cases and the differences between the various API systems. It also includes the detail that draftId and storeId are always the same value: obvious to someone who knows the platform, but exactly the kind of thing that trips up a model that does not know the entire platform.
webround-frontend.md covers everything needed to write custom React components: how to structure a component with the wr prop, how to handle internal navigation in the shadow DOM, how to use Tailwind v4 and how to handle some basic functions.

I was starting to understand something simple: you do not need a proprietary AI editor system. You just need the right context to make the AI work correctly.

What I took away from this

The appeal of an AI website builder is real, especially when you see others building them and the marketing around these features keeps getting louder. But when a feature does not add real value beyond convenience at the expense of control and quality, it becomes clear that investing in it, at least right now, does not make sense.

The platform is already open enough that it does not need a proprietary AI intermediary: I was adding non-essential complexity in exchange for a credit system or cost premium that was not always justifiable.

At the moment, I have put development on hold without archiving the idea. There will probably be iterations on this in the coming months with more specific, more targeted details and more granular integrations. Part of me feels this feature is important, but maybe that is just FOMO. Another part knows I would have gained almost nothing from it except a slightly more convenient workflow.

For now, the context files are enough.

Download the context files for Webround

If you are building on Webround with an AI assistant, these files are ready to use:

If you need the full API specs or the complete frontend type definitions, these files are available too. I would not recommend pasting them directly into a chat message since you would burn through an enormous number of tokens. I use them as a knowledge base inside a Claude Project, which retrieves specific information without consuming too many tokens thanks to the tool use and the RAG it builds automatically over project files.