How Vorx builds an app

Every AI app builder demos well. The difference between a demo and a tool you can trust with a real product is everything that happens between your prompt and the running app. This post walks through that pipeline at a high level: what Vorx actually does when you press enter.

First, understand what you're asking for

Not every message is a build request. "Make the invoices page", "make it feel warmer", "the save button doesn't work" and "add a photo of a mountain here" are four very different jobs, and treating them all as "regenerate some code" is how builders wreck work you were happy with.

So the first thing Vorx does with any instruction is classify its intent - semantically, with a model, never by keyword matching. A message about a bug routes to diagnosis. A styling note routes to a restyle that leaves your logic alone. A scoped edit touches the one screen you mentioned and nothing else. Getting this routing right is unglamorous, but it's the foundation everything else stands on: the pipeline can only be careful if it first understands what kind of careful to be.

Stage A - design before code

For anything that needs building, Vorx doesn't start writing code. It starts by working out what to build: the screens, the entities and the relationships between them, which flows matter most, and a visual direction that fits what you described.

The output of this stage is a design spec, not code. That separation matters for two reasons. First, design decisions are cheap to make and expensive to unwind - moving "invoices belong to clients" from a sentence in a spec to the right place in a schema, an API and four screens is exactly the kind of thing you want settled before generation starts. Second, the spec becomes the shared source of truth for everything downstream: generation, verification and later edits all read from the same description of what the app is supposed to be.

The design stage also decides scope. On an existing app it selects which files are actually involved in your request, so an edit to the settings page never becomes an excuse to rewrite the dashboard.

Stage B - generation with a whole-app view

Then Vorx writes the app: components, routes, the data model, and the backend wiring that connects them.

The interesting choice here is coherence. It's tempting to parallelize - fan out one model call per page and merge the results. We've measured that approach extensively, and the coherent path wins: generation runs over a shared context that contains the design spec and the app's real state, so every piece is written by something that can see the whole. That's why the list page, the detail page and the schema agree with each other, why navigation doesn't link to screens that don't exist, and why the styling reads as one product rather than five stitched-together generations.

Generated apps aren't static mockups either. They come with the unfashionable parts included: authentication, a real database behind real queries, and sync so that two people looking at the same record see the same thing.

Verification - the app has to actually work

This is the stage most builders skip, and it's the one we'd keep if we could only keep one.

Before you ever see a build, Vorx renders it in a headless browser. Not a syntax check - a real render, watching for runtime errors the way a user's browser would hit them. For apps with a backend, it goes further: it logs in as a test user and clicks through the primary flows. Can you sign in? Does the main list load? Does creating a record actually create it?

When something fails, Vorx doesn't hand you the error. It reads the failure, fixes the code, and runs the check again. Only a build that passes gets presented. And because false alarms erode trust in the other direction, a suspected runtime error is confirmed before Vorx offers to fix it - we'd rather verify twice than cry wolf.

That loop is the honest answer to "how is this different from pasting my prompt into a chat model?" A chat model gives you code. A pipeline gives you code that has already survived contact with a browser.

Editing without collateral damage

Most of an app's life is edits, and edits are where trust is won or lost. The pipeline treats an edit fundamentally differently from a build: intent classification decides how invasive the change should be, the design stage selects the minimal set of files involved, and generation is constrained to them. A restyle can't drop a database column. A copy change can't rewrite your checkout flow.

Bigger changes go through a plan you approve first, and while an approved plan builds, you can watch it apply - and stop it - rather than waiting on a spinner and hoping.

What we deliberately don't do

A few non-features, because they're as load-bearing as the features:

• No keyword routing. Intent is always judged from meaning in context. Word-list shortcuts are cheaper and confidently wrong.
• No unverified builds. If the interaction check can't get through the primary flows, you don't get the build - you get a build that's been fixed until it passes.
• No mock data theater. The backend is real from the first generation, because retrofitting reality into a mockup is where "it demoed great" projects go to die.

None of this makes a flashier demo. All of it is why the app still works in week three.