Docs

Building Apps

Writing a prompt that works, the prompt-preview-review loop, and the ways to keep your code.

Chapter 01

Create or remix

Start from a prompt when you know the workflow you want. Use Remix when a public template is close to your target app. Remix creates an independent project in your workspace.

Example promptBuild a CRM dashboard with leads, customer notes, status filters, and a follow-up date field.

Chapter 02

Writing a prompt that works

The model is good at building what you describe and bad at guessing what you left out. A useful prompt names the records, who can see them, and what the screen should do.

Say what the data is

"A booking app" can be built a hundred ways. "Services with a duration and price, appointments with a customer and a time slot, and a day view for staff" can be built one way.

Say who sees what

Roles are cheap to ask for up front and awkward to retrofit. "Staff see only their own jobs; the manager sees everything" changes the data model, not just the screens.

Say what happens, not how to code it

"Reject the claim and send it back to the employee with a required comment" is better than naming components or hooks. Describe the behaviour and let the generator choose the implementation.

One change at a time

A prompt covering one screen, one layout change or one fix is easy to review and easy to undo. A prompt covering six things produces a version where five worked.

Example prompt

Add an approval step to expense claims: anything under 5000 needs only the manager, 5000 and above also needs finance. Rejection requires a comment and returns the claim to the employee for editing.

Chapter 03

The iteration loop

Prompt a focused change.
Wait for the preview build.
Review the UI, its empty and error states, and the mobile layout.
Send a follow-up prompt, or roll back to a prior version.

Reviewing after every step is what keeps this cheap. If you send five prompts and then look, you have to work out which one broke the thing you just noticed; if you look after each, you already know.

Roll back rather than prompt your way out

When a change makes things worse, returning to the last good version is faster and cheaper than asking the model to undo itself. Every build is a version, so nothing is lost.

Chapter 04

Code ownership options

Push to GitHub commits the selected NeoBuild version to your repository.
Pull from GitHub imports external repo changes into NeoBuild.
Download ZIP exports a version for local development.
Upload ZIP imports an existing React project into NeoBuild.