Build time

Why a Virex build takes 5-15 minutes

The honest answer: because we generate the whole multi-page app at once, not a single landing page. Here is exactly what the engine is doing during the wait, what comes out, and what we're working on to make it feel shorter.

Back to docs Read the build guide

One sentence

Other AI builders generate one page in 2 minutes. Virex generates 10-15 unique pages, a working auth flow, a localStorage demo backend, and a download-ready Next.js repo — in 5-15 minutes. You wait a bit longer; you walk away with a whole app.

What happens during the wait

The engine is running 9 phases

Each one matters. Skipping any of them is what makes other tools faster but shallower.

1
Intake (Haiku, 2 credits, ~3s)
We read your prompt and extract the project name, type, audience, vibes, color hints, and which pages you actually need. This is what makes /pricing show on a SaaS build but not on a portfolio.
2
Path routing + design tokens (Haiku, 1 credit, ~2s)
Pick a color/font/radius preset that matches your vibes + tone, or vary one with Haiku for richer brand identity. Tokens get applied across every section as CSS vars.
3
Domain data synthesis (Sonnet, ~15-30s)
For app types (saas, crm, ecommerce, dashboard) we generate the real entities your app is about — actual products, countries, airlines, cases. These show up as content on list pages instead of generic 'Item 1, Item 2' placeholders.
4
Section selection (~2s, free)
Pick 5-8 section variants from our 140-section library (heroes, features, pricing, testimonials, CTAs, etc.) that match your project type + vibes.
5
Section customization (Sonnet, 5 credits each, ~5-10s per section)
Fill each picked section with copy specific to your brief. This is what makes a Virex pricing page feel different from another Virex pricing page even if they pick the same variant.
6
Page composition (Sonnet, 60 credits/page, ~30-90s per page)
For app types we generate 10-15 unique full pages via LLM — /dashboard, /clients, /cases, /settings, etc. Each page gets its own creative angle, its own layout, its own real content. This is the big time sink, and it's where the value lives.
7
Schema + RLS (~5s)
For backend-shaped apps we emit a Supabase schema.sql + migrations + seed.sql with row-level security policies. Ready to paste into Supabase Studio.
8
Assembly + ZIP upload (~10s)
Stitch every file together, write package.json + Tailwind config + the auth shim, zip it, upload to storage. Now you can download the entire repo.
9
E2B sandbox boot (~60-180s, first run)
Spin up a Firecracker microVM, run npm install for ~40 deps, start next dev. After this finishes, you get the live interactive preview. Subsequent edits skip npm install and reboot in seconds.

Why not faster

The boring honest answer

Most of the time is Anthropic's API processing your pages. We can't make their LLMs faster — but we can hide the wait by showing you what's been built so far while the rest cooks.

Bolt / v0 / Lovable generate 1-3 pages

A landing page. Sometimes a dashboard. Often you have to prompt again to add the next page. Each prompt is its own build cycle. You can fit one in 2 minutes because it's one page.

Virex generates 10-15 pages in one shot

Your build comes out with /, /login, /signup, /dashboard, /clients, /cases, /settings, /reports, /pricing, /about — wired together with a working nav, an auth shim, and a demo store. One prompt, whole app.

Concurrency is capped at 4

Anthropic's Tier 1 lets you run ~5 LLM calls in parallel. We cap at 4 so we never hit the rate limit and stack queued requests. Above the cap, Anthropic queues silently and the build feels stuck.

Some pages need retries

Sonnet sometimes ships pages with an unclosed JSX tag or a forbidden import. The validator catches it and retries with the warning attached. ~3 out of 15 pages on average need one retry.

What we do to hide the wait

The build is not a black box

During those 10 minutes the preview is doing real work that lets you start using the build before it's finished.

Pages appear in the preview one-by-one as the engine finishes them. You can click through /dashboard, /clients, /settings before the build is done.
The chat panel narrates each phase live — domain data, section picks, per-page compositions, schema, assembly.
Once the live sandbox is up, edits are seconds, not minutes. The wait is one-time per new build.
The downloaded ZIP is a real Next.js repo. `npm run dev` works locally without needing the Virex platform.

What's next

Things we are still cutting from the build time

Build time matters. Here is the roadmap we're shipping against.

Streaming Sonnet output per page — tokens appear in the preview as the LLM writes them instead of in a single chunk at the end.
Section-level reuse cache — if your prompt matches another recent build closely, lift the customized sections directly instead of regenerating.
Higher-tier Anthropic concurrency for paid plans — more parallel calls = total wall-time drops.
Smarter validator — fewer false-positive rejections of valid Sonnet output means fewer retries per build.

One last honest note

A 10-minute wait will feel long if you're staring at a spinner. It does not feel long when you're clicking through real pages of your own app as they appear, refining the prompt for the next build, or grabbing coffee. We're optimising for the third option to never be necessary.

Edit cycle, not build cycle

After the first build, every change is an edit — typically 30-60 seconds end-to-end (chat, propose, validate, apply, snapshot). Build time is one-time per new project. Edit time is your daily loop.