How Vorx works

Under the hood: the two-stage pipeline that turns a prompt into a working app, the verify step that keeps it working, and the runtime it ships on.

Every build runs through the same pipeline. Knowing the shape of it helps you write better prompts and understand what Vorx is doing while you wait.

Stage A — design

First Vorx works out what to build: the screens, the entities and how they relate, and a visual direction. This stage produces a design spec rather than code, which keeps the expensive generation stage focused and coherent.

Because design comes first, naming your entities up front ("projects have tasks; tasks belong to a user") pays off — it lands directly in the spec. This is also why Plan mode is useful: it lets you read and correct the thinking before any code exists.

Stage B — generation

Then Vorx writes the app: components, routes, the data model, and the backend wiring, in one pass over a shared context. Generating the app coherently in a single pass produces a more consistent result than stitching together many isolated pieces.

Verify

Before you ever see it, Vorx renders the app in a headless browser, signs in as a test user, and clicks through the primary flows. If a page throws, it fixes it and tries again. That verify step is the difference between a demo and something you can actually use.

It's also why a first build takes several minutes rather than seconds — you're waiting on a working app, not a first draft.

VorxSync — on the roadmap

VorxSync is the local-first sync layer we're building: writes would hit a local store first (instant UI), stream between users in realtime, and keep working offline. It isn't in the apps you build today — see Vorx Apps vs standard apps for what ships now.

What a run costs

A build or edit is charged on the real model spend for that run, converted to whole credits — minimum one per charged run. Design, generation and verify are all part of the same run and the same charge. Runs that don't call a model at all, like an undo, are free. See Plans and credit usage.

Your code

The output is a real, conventional codebase you can read, edit, and export. Connect a repository under Settings → GitHub to push it out, and nothing about the pipeline locks you in — you can take the repo and run it anywhere.

The Code view: the project's real file tree and source, beside the chat that wrote it

Next steps

Writing good prompts — how to feed stage A well
Fixing errors — what to do when verify didn't catch it
Core concepts — the vocabulary