Your AI Builder's Export Looks Fine. Does It Actually Build?

The usual advice about AI builders is to check whether the export is real code — a normal project directory, named npm dependencies, no proprietary runtime, nothing that needs the vendor's CLI to run. That advice is right, and we have made the case for it ourselves.

It is also not sufficient. An export can pass every one of those checks — standard Next.js, four dependencies, opens fine in VS Code — and still fail on the first npm run build. Real code and working code are different claims, and only one of them is usually tested.

Why this happens: the preview and the export are different programs

Almost every visual builder has two ways of turning your design into output, and they are written by different code:

• The renderer takes the design tree and draws it in your browser. This is what you see in the editor and in any hosted preview.
• The exporter takes the same tree and writes it out as source files. This is what you download.

The two agree right up until the design tree contains something malformed. AI generation produces malformed values routinely — a heading level stored as the number 1 instead of the string "h1", a list of dropdown options arriving as an array where a comma-separated string was expected, a colour written three different ways.

Renderers are written defensively, because a renderer that throws blanks the screen and gets noticed immediately. So the renderer coerces the number 1 into an h1, shrugs, and paints a perfect heading. Exporters tend to be written optimistically, because nobody is watching them run. The exporter interpolates the same value straight into a template and writes <1> into your page file.

<1> is not valid JSX. That file will never compile. And nothing on screen ever hinted at it, because the screen was drawn by the other program.

This is the worst shape a bug can have

Consider when you find out. Not while evaluating — the previews looked great. Not while designing — the editor was fine. You find out after you have chosen the tool, paid for it, built the client site, and hit export on the afternoon of the handoff.

It is also invisible to the vendor unless they deliberately test for it. Their editor works. Their hosted previews work. Their own marketing screenshots work. Every surface they look at every day runs through the renderer. The exporter is the one path nobody exercises, and it is the only one the customer takes home.

The five-minute test

Run this against any builder before you commit a client project to it.

1. Generate something with structure. Not a hero and a button — a page with several heading levels, a form with a dropdown, a list, and an image. Malformed values hide in variety.
2. Export it and run the production build. npm install && npm run build. Not npm run dev. Dev servers compile lazily and forgive a great deal; a production build compiles and type-checks everything at once, which is the point.
3. Grep the output for the tell. Search the generated files for <1, <2, undefined, [object Object] and NaN. Each is a value that reached the file without being checked. Finding one means the exporter does no validation, so assume there are others.
4. Compare the build against the preview. Where the build succeeds, run it and put it next to the preview. Missing sections and collapsed layouts mean the two paths disagree in a quieter way.
5. Check the dependency list. Open package.json. Every entry should be a package you recognise from npm. A dependency on the vendor's own scope is the lock-in the other checks are looking for.
6. Ask whether the exporter is tested. This is the question that predicts the others. A vendor who tests every template through the exporter on every commit will not ship <1>. A vendor who has never thought about it will, eventually.

Why this matters most for agency and client work

If you are building for yourself, a broken export costs you an afternoon and some swearing. If you are delivering to a client, the export is the deliverable. It is the thing that goes in the handoff, the thing their in-house developer opens, and the thing your invoice is attached to. "The builder I chose produces code that does not compile" is not a sentence with a good ending.

This is also why the check belongs in your evaluation rather than your first project. The cost of running it is five minutes. The cost of skipping it is discovered at the worst possible moment, by the person paying you.

Where InBuild stands on this

We will not ask you to take our word for it. InBuild's exporter runs in continuous integration against every starter template that ships: each one is generated and then parsed with the TypeScript compiler, asserting zero syntax errors and no numeric tags. If the exporter ever writes <1>, the build fails before the change lands.

You can also just read the output. Every template is rendered live on our examples page, next to the exact files the export produces — the page component, the package.json, and the full file list. No account, no card. Run the checks above against it and decide for yourself.

The bottom line

"Exports real code" is a claim about file format. "Exports code that builds" is a claim about correctness, and it is the one that determines whether you can actually ship. They are not the same claim, most feature comparisons only check the first, and the difference does not surface until you are already committed.

Run npm run build. It takes five minutes and it is the only part of an AI builder's marketing you can verify yourself.