How to write a first prompt that builds the right app

The first prompt you give Nest sets the shape of everything that follows. It decides the database tables, the pages, who can sign in and what they see. A good first prompt does not need to be long. It needs to answer a few questions that Nest would otherwise have to guess.

Here is what we have learned from watching thousands of projects start.

Say four things

Before you type, think about these four points. You can write them in any order, in plain sentences.

1. Who it is for

Name the people who will use the app, and if there is more than one kind, say how they differ. “Gym members and the front desk staff” tells Nest it needs two roles with different screens. “People” tells it almost nothing.

2. The three things they do

Pick the three actions that matter most. Not ten. Three. A class booking app might be: browse the timetable, book a spot, cancel a booking. Everything else can come later, and Nest will build those three well instead of building twelve things halfway.

3. What data exists

Say what the app stores and how the pieces relate. “Classes have a time, an instructor and a capacity. Members can book many classes.” That one sentence gives Nest a clear Postgres schema. If you already have data, say so: a spreadsheet you will import, or an existing Stripe account.

4. What is out of scope

This is the step most people skip, and it saves the most time. If you do not want payments yet, say so. If there is no mobile app, say so. Ruling things out keeps the first version small and easy to review.

Before and after

Here is a real first prompt, lightly edited, and the version we suggested instead.

The first version is not wrong, but Nest has to invent who “I” is, what “stuff” means and how payment should work. The second takes thirty seconds longer to write and produces an app that is right on the first try.

Then iterate in small asks

Once the first version is live, resist the urge to send one long list of changes. Small, focused messages work better, for three reasons:

• Each change is a version. If one ask goes wrong, you roll back that one step and keep the rest.

• You review as you go. It is easy to check one change in the preview. It is hard to check eight at once.

• Nest has less to hold in mind. A single clear goal leads to a cleaner edit than a paragraph of mixed requests.

A good rhythm looks like this:

1. “Add a waitlist when a class is full. Notify the first person by email when a spot opens.”

2. “Show members their upcoming bookings on the home page.”

3. “Let staff mark a class as cancelled and email everyone booked into it.”

4. Now add payments, once the core flow feels right.

If a change is larger, like adding team accounts or a full billing flow, ask Nest to write out its plan before it starts. Reading a short plan lets you correct the approach before any code changes.

A few more tips

• Use your own words. You do not need technical terms. “Only staff can see this page” is as clear to Nest as any description of roles and permissions.

• Point at the screen. If something looks off, click it in the preview and describe the change there rather than explaining where it is.

• Start from a template. If your idea is close to a booking app, a CRM or a client portal, browse the templates and start from one. Your first prompt then becomes a list of what to change.

The best first prompts read like a note to a capable colleague. Say who it is for, what they do, what you store and what you do not need yet. Nest will take it from there.