A complete walkthrough of what you actually see when you build an app here — captured start to finish while building a real booking site for a hair salon.
Every screen is the live product. Where a step was driven by something typed into the app, the exact wording is shown with it — so this doubles as a script you can follow.
The entry screen. Three starting points — a website, a mobile app, or a mobile app with accounts and sync. Everything else is one plain-English description; no technical questions yet.

The brief is written the way you would explain it to a person: who uses it and what they do. Nothing here names a framework, a database, or a page structure.
A booking site for a small hair salon: clients browse stylists and services, pick a time slot, and book an appointment. Owner sees all bookings in an admin dashboard.

Rather than guessing, it comes back with a handful of targeted questions — each paired with a note on why it matters, like determines guest vs. authenticated booking flow. All of them are optional.

Two answers here change the shape of the product. Both show up in the plan and in the data model.
Guests can book without an account; only the owner logs in. Each stylist has their own list of services.

Twenty to forty seconds, with the plan streaming as it is produced so the wait is visible rather than a spinner in the dark.

A named project with a summary, the stack it will use, who the users are, and the business rules it intends to enforce — including the guest-booking decision made two steps earlier.

Every feature is sorted into a group and tagged must-have, should-have or nice-to-have. This is the moment to disagree — you can edit the prompt and re-plan, or approve and start building.

Approving scaffolds a working starter and starts its containers. It is deliberately a starting point, not a finished product — the plan is what you build against next.

A live preview on its own address, with tabs for files, the terminal, review, a browser and secrets. The app is already served and reachable at this point.

Before the terminal will do anything, Settings needs your own Claude subscription connected, so builds and terminal sessions run under your account and your usage. It is a one-time step: choose to connect, authorize on Claude's own sign-in page, and paste the code back. Expo is separate and only needed if you want a mobile app as an installable Android APK.

The Terminal tab opens Claude directly in the project workspace — this is where the app gets built out from the plan. It confirms access to the folder before touching anything.

It reads the project architecture guide, breaks the work into data model → API → page, and hands the schema step to a specialist agent. You watch it work rather than waiting on a black box.
Build the stylist list page from PLAN.md as my first screen

Before building anything substantial, Claude can put a plan here as a page you click, mark up and comment on — your notes go straight back to it, instead of a wall of text in a terminal. It starts empty; the next step is how you fill it.

You have to ask for this. Claude then writes the plan as a page instead of prose and waits: “I've put the plan in the Review tab — open it, click anything you want changed and leave me a note.”
Before you build the booking page, plan it by making use of the lavish editor so I can review it

The Review tab now holds a real plan for the booking page — the route it will live on, the goal, what exists today, and the intended behaviour — with an annotation panel beside it.

Click any part of the page to attach a note, or type a message. A product decision, expressed the way a non-developer would express it.
Looks right. One change: let guests pick the time slot before entering contact details, not after.

Claude picks the note straight out of the browser and revises the plan — the contact form now stays disabled until a time is chosen. Nothing has been built yet, which is the point: the correction costs seconds instead of a rebuild.

Its reply appears in the same panel: what changed, and a check that this is what you meant. You approve, or send another note. Only then does it build.

Testing starts with a connection. The Browser tab attaches you to a real browser running next to your app — empty until something opens in it. This is the screen you watch the tests happen on.

Ask it to test the site and it drives this browser for real — here the app is loaded at its own address, with the page, tab title and cursor all visible. Not a screenshot it took privately: the same window you are looking at.
Now test the app for me: write a Playwright test that opens the site in the headed browser on the display in .display so I can watch it in the Browser tab, then run it and tell me what you saw.

The useful part is the honesty. It reports the page loaded — HTTP 200, TLS fine, title “salon-booking” — then says plainly that it never read the page content, so it cannot claim the feature works, and names what is genuinely unfinished. A test that reports “passed” without checking is worse than no test.
In one short paragraph: what did you actually see in the browser just now, and what is still missing?
