Break a big build into steps

It's tempting to describe your whole app in one enormous prompt. Large apps come together faster and more reliably in layers: a solid core first, then one feature at a time, each verified in the preview before the next goes in.

Sketch the whole thing first

Before you prompt, jot down what the app needs. Not a spec — a short list:

• The main entities (Tasks, Projects, Users)
• The key screens (list, detail, settings)
• Who logs in and what they can see

That list becomes your build order. You're not committing to it forever, but it stops you wandering, and it makes it obvious when a request is really two requests.

Start with the core loop

Every app has one thing users do most. Find it and build that first. For a project tracker it's creating and viewing tasks; for a booking tool it's picking a slot.

Keep the opening prompt on that loop and nothing else:

Build a task tracker where a user can create tasks with a title, due date and status, and see them in a list.

Once that works in the preview, you have a foundation to refine instead of a blank page.

Add features one prompt at a time

With the core in place, layer on capabilities in small, self-contained requests. Each should describe one change you can check at a glance:

• Group the task list by status into To do, In progress and Done columns.
• Add a priority field with Low, Medium and High, and let me filter by it.
• Add a detail view for a task with a notes section and an activity log.

Smaller steps are easier for Vorx to get right and easier for you to check. If something is off, you know exactly which change caused it — and because every change is its own checkpoint, you can roll back that one step rather than unpicking a pile of them.

Plan the big ones before you build them

When a step is genuinely large — a whole new section, a change that touches several screens — switch the composer to Plan mode first. Vorx describes the screens and data changes it intends before writing code, which is the cheapest possible moment to catch a wrong assumption. Approve it, switch to Build, and let it run.

Verify before you move on

After each prompt, use the preview. Click the new feature, add a record, confirm it saved. Narrow the window to phone width if that matters for this app.

Catching a problem now is far cheaper than finding it five features later, when you can no longer tell which step introduced it.

Refine in place, don't restart

When a screen is close but not right, describe the adjustment rather than rebuilding:

On the task detail page, move the notes above the activity log and make the save button primary.

Scoped edits leave the rest of the app untouched. Save sweeping prompts for genuinely new areas.

Know when to branch out

Once the core is solid you can safely add whole new sections — a dashboard, a settings area, an admin view. Treat each as its own mini-build: sketch it, build its core loop, layer in features.

Building in steps isn't slower. It's how you reach an ambitious app without losing the thread.

In the docs: Build and Plan modes and Iterating in chat.