How Fulta builds an app: planner, builder, reviewer

Most AI builders show you a spinner and then a result. We think you should be able to watch the work, so this is what happens between your sentence and the preview URL.

One prompt, several roles

A build is not one model call. It is a short pipeline, and each step has a job:

• Planner — reads your prompt and decides what the app actually is: which pages exist, what data it stores, what a visitor can do. This is where "a site for my salon" becomes six pages, a services table and a booking model.
• Builder — writes the code inside an isolated sandbox. It has access to the project's real files, not a blank buffer, so a change in the tenth prompt is aware of what the first nine produced.
• Reviewer — opens the finished app in a real browser and uses it. Not a screenshot: an actual page load, actual clicks, actual form submissions.

Between the builder and the reviewer, the platform runs its own checks: the project has to build, type-check and pass its tests before anything gets shown to a person.

Why a reviewer matters more than it sounds

Code that compiles can still be wrong in ways only a user notices: a button that goes nowhere, a form that silently fails, a layout that collapses at 390 pixels wide. A reviewer that drives the app in a browser catches the class of problem that static checks never will.

When it finds something, the run goes into a bounded repair loop. The builder gets the specific failure, fixes it, and the checks run again. You only hear about a failure if repeated repairs genuinely cannot fix it — and then you get a sentence in plain language, not a stack trace.

Every run is recorded

Each build stores what was asked, what the plan was, which files changed, what it cost and which version it produced. That has two useful consequences:

1. You can go back. Every successful build is a version, and restoring one is a normal action rather than an emergency.
2. We can measure. Because each run also stores a snapshot of the engine configuration that produced it, we can compare engines against benchmarks and see whether a change actually made builds better, rather than just different.

What we are still working on

Honest list, because the beta label is not decoration:

• Asking better questions up front. A short clarifying exchange before the first build beats a long repair loop after it.
• Faster first builds. Most of the wait is real work, but not all of it.
• Better progress language. "Writing the booking form" is useful. "Running node 4 of 7" is not.

If you want to see it work, describe something on the home page and watch the build happen. The free plan is enough for a first app.