Your first project

A project starts with a description. The more concrete you are about screens, people and data, the better the first version.

Describe the app in a paragraph

Open a new project and type something like:

A booking tool for a small photography studio.
Customers pick a session type, see available dates on a calendar,
and request a slot with their name and email. I need an admin view
where the studio owner can confirm or decline requests.

That is enough to get started. Notice what is included: who uses it, what they do, and the two screens that matter. You do not need to describe colours or layout yet.

Review the plan

For larger requests the builder may show a structured plan you can read, edit and approve before it starts. It may also ask a short question, such as "Should customers pay a deposit?", which is easier to answer now than to unpick later.

If you would rather not decide, say "just build it". It will make reasonable choices and tell you what it assumed.

Watch the first version appear

The builder works through the project in steps and the preview updates as it goes. When it finishes, you get a summary of what it built and what it left out.

First builds take longer than later changes, which are usually much faster.

Try it before you improve it

Use the app the way a real person would: create a record, refresh the page, sign in as the other role, submit the form twice. This is the cheapest moment to notice that the booking page has no timezone, or that the admin view shows everyone's requests.

Then write down the three things that bothered you most and fix them one at a time.

What "done" looks like for a first version

A good first version:

• Lets one real person complete the main task start to finish.
• Saves data, so a refresh does not lose it.
• Looks like it belongs to you, not like a demo.
• Is something you are happy to show a colleague.

From there, customise the look or invite someone to try it.