# Build a booking app

> A complete app, end to end: first prompt, refinement, sign-in and roles, a real privacy test, publish, and a domain.

In this tutorial you build a complete booking app for an imaginary salon and take it live: first prompt, refinements, sign-in, a real privacy test, publish, and a domain. Budget about fifteen minutes of your attention plus a few minutes of the agent building. If this is your first app, skim the [quickstart](/docs/getting-started/quickstart) first; this tutorial goes further.

### Describe the whole app in one message

From your dashboard, start a new project with this prompt (adjust freely):

> Build a booking app for a hair salon called Salt Studio. Customers pick a service (cut $60, color $140, blowout $45), then a date and a free 30 minute slot on weekdays 9 to 5, and book it with their name, phone, and email. I need an owner page listing the day's bookings in order. Clean and calm, sage green and cream.

**What you should see:** the build workspace opens, the agent narrates what it is creating, and after the build the preview shows a styled salon site with your three services. It will not be perfect yet; that is the next step.

### Refine what the first pass got wrong

Look at the preview as a customer would and correct specifics, one message per concern:

> The booking flow should not allow past dates, and Sunday should not be offered at all.

> Rename the "Submit" button to "Book my slot" and show a confirmation screen with the details after booking.

**What you should see:** each request rebuilds just what it touches, and the preview updates. This describe-look-correct loop is the whole craft; the [prompting guide](/docs/building/better-results) sharpens it.

### Add sign-in, shaped to the business

The customer flow should stay frictionless, but the owner page is private:

> Add sign-in. Booking a slot should not require an account. The owner page requires sign-in, and only admins can open it; hide its link from everyone else.

Then open **Vault → Auth → App Users**, sign up in the preview with your own email, and promote your account to admin.

**What you should see:** the preview's owner page now refuses you until you sign in, and after your promotion it opens. New accounts (role "user") still cannot open it.

### Test the privacy like you mean it

Create a second test account in the preview and leave it unpromoted. Check both directions: the admin sees the day's bookings; the second account gets refused from the owner page even when pasting its address directly.

**What you should see:** a refusal for the ordinary user. If both accounts can see the owner page, tell the agent; this test existing is why the launch version will not surprise you. The same two-account habit covers [data privacy](/docs/data/data-privacy) in general.

### Publish

Press **Publish**. Vaulter builds the production version and puts it on your app's own vaulter.run address.

**What you should see:** a live URL you can open in a private browser window. Walk the whole flow once there: book a slot, sign in, check the owner page. The [preview vs published](/docs/publish/preview-vs-published) page explains the difference between the two environments.

### Give it a real address

In **Vault → Domains**, either [buy a domain](/docs/publish/buy-a-domain) inside Vaulter (it connects itself) or [connect one you own](/docs/publish/connect-domain) with two DNS records. Wait for the status to reach **Active**; SSL is automatic.

**What you should see:** your app on your own domain, with a padlock. Share previews and search behavior are worth a minute next; see the **SEO** tab and [the SEO page](/docs/growth/seo).

## Where to take it from here

- Email confirmations for every booking: the [Resend guide](/docs/integrations/resend).
- A Slack ping when a booking lands: the [Slack guide](/docs/integrations/slack).
- Real availability against your own calendar: the [Google Calendar guide](/docs/integrations/google-calendar).
- Watch bookings convert: [Analytics](/docs/growth/analytics).