Writing good prompts

The quality of a build tracks closely with the prompt. None of this is about clever wording — it's about giving Vorx the same context you'd give a good engineer.

Name the user

Say who the app is for and what they're trying to do. Compare:

An expenses app.

An expenses app for field engineers who photograph receipts on their phone and submit them for a manager to approve.

The second tells Vorx about the screens, the input method, and the roles — all from one sentence.

List the nouns

Name the core entities and their key fields. "Invoices have a client, line items, a due date, and a status" gives Vorx a data model that matches how you think about the business, instead of one it has to guess.

This lands directly in the design stage, which runs before any code is written — so naming entities up front is the cheapest way to steer a build. See How Vorx works.

Describe one flow end to end

Walk through the single most important journey: "A manager opens the dashboard, sees pending approvals, opens one, and approves or rejects it with a comment." One concrete flow anchors the whole build.

Say what it should not do

Scope is easier to add than remove. If you don't want multi-currency, a public sign-up page, or a dark mode, say so up front.

Iterate in small steps

After the first build, change one thing at a time. Small, specific edits land more reliably than a rewrite, and they're easier to review in the preview.

Show, don't just tell

Attach a screenshot of an app you like or a spreadsheet of your data. Vorx builds from what it sees, so a reference image often beats a paragraph of description. You can attach up to 10 files per message — see Usage and limits for the size caps.

Plan the big ones

For anything large or ambiguous, send it in Plan mode first. You get the approach in writing and can correct a wrong assumption before it becomes code.

A prompt worth copying

Build a booking tool for a two-room physiotherapy clinic.

Users: receptionists (create and move bookings) and physios (see only their own day).
Entities: clients (name, phone, email, notes), physios (name, room), bookings
(client, physio, start time, 30 or 60 minutes, status).
Core flow: a receptionist opens today, sees both rooms side by side, drags a
booking to a new slot, and the physio sees the change immediately.
Don't build: payments, or a public self-service booking page.
Seed a fortnight of realistic bookings.

It names the users, the nouns and their fields, one flow end to end, the scope to leave out, and asks for seed data — which is most of what a good build needs.

Next steps

• Iterating in chat — the rhythm after the first build
• Build and Plan modes — when to plan first
• Your data model — how the nouns become tables