Prompting basics: describe, don't spec

How you describe an app shapes what Vorx builds. You don't need a formal spec — you need a clear picture. The goal isn't to itemise every screen; it's to give Vorx enough to make good decisions on your behalf.

It helps to know that Vorx designs before it generates. Your prompt lands first in a design stage that works out the screens and the entities, and only then does anything get written. That's why the nouns you use matter so much, and why a sentence about who the app is for is worth more than a list of fields.

Describe, don't spec

The shift from traditional tools is that you're not assembling anything. You're explaining what the app is for and who uses it, in the language you'd use with a colleague.

"A tool where coaches schedule sessions and clients book open slots" tells Vorx far more than a list of fields ever could.

Name the user

Who the app is for changes almost every decision — layout, defaults, what's on the home screen. Name them.

An expenses app for field engineers who submit receipts from their phone

That beats "an expenses app" by a mile. The first version tells Vorx to prioritise a fast mobile capture flow; the second leaves everything to guesswork.

List the nouns

The nouns in your description usually become the entities in your data model, so naming them keeps the model matching how you think about the work:

• Invoices, clients, line items for a billing tool
• Contacts, companies, deals for a CRM
• Patients, appointments, notes for a clinic scheduler

Say how they relate — "tasks belong to a project; a project has one owner" — and name the fields that matter. "An invoice has a due date, a status and a total" is plenty; Vorx picks the types.

If your nouns already live in a spreadsheet, better still: attach it, and the data model is built from your actual columns rather than a guess at them. See Build from a screenshot or a spreadsheet.

Describe one flow

Pick the single most important journey and walk it end to end. For an expenses app: snap a receipt, enter an amount and category, submit for approval, get notified when it's paid.

One flow described in full is worth more than five flows sketched halfway, and it does two jobs. It tells the design stage which screens are load-bearing. And because Vorx verifies a build by actually clicking through the primary flows in a browser before showing it to you, a clearly described flow is a flow that gets exercised — the thing you care most about is the thing that's been checked.

Say what it should not do

Scope is easier to add than to remove. If you don't need multi-currency, team roles or a public sign-up page yet, say so. A tighter first build is faster to review and easier to get right.

"Keep it to a single user for now — no sharing or roles yet" is a perfectly good line to include.

When the stakes are high, plan first

For an ambitious first prompt, switch the composer to Plan mode. Vorx proposes the screens, the data changes and the steps before writing any code, so you can read its interpretation of your prompt and correct it while correcting is cheap. A plan you disagree with is useful information — reply to it rather than starting over.

Iterate one change at a time

Once the first version is up, resist packing ten fixes into one message. Ask for changes one at a time so you can see each result and catch anything that drifted. Small, specific prompts — "Add a status badge to each row" — are easier for Vorx to apply cleanly and easier for you to verify.

There's a mechanical reason too. Vorx works out what kind of change you're asking for and scopes the edit to match: a note about styling leaves your logic alone, and a tweak to one screen doesn't disturb the others. A five-part rewrite forces a broader change than most of those five parts actually needed.

And if a prompt lands badly, roll back rather than patching over it. Rollback is free, so re-running a better-phrased request from a clean checkpoint usually beats three corrective messages.

Putting it together

Weak:

Make me a project management app.

Strong:

A snag-list app for a small building firm. Site foremen photograph defects on their phone and log them against a job; the office manager sees all open snags, assigns them to a subcontractor, and marks them closed. No client logins, no invoicing.

Two sentences and a boundary. That's a user, the nouns, a flow end to end, and what's out of scope — everything the design stage needs to build the right thing first time.

And if the first build isn't right? Say what's wrong the way you'd tell a colleague. There are no magic words to learn: Vorx reads your message for what you mean, not for keywords. Just be specific about what you want different, one thing at a time.

For the full walkthrough from prompt to publish, see Build your first app.

In the docs: Writing good prompts and Build and Plan modes.