Build a booking app

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 first; this tutorial goes further.

1. 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.

2. 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 sharpens it.

3. 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.

4. 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 in general.

5. 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 page explains the difference between the two environments.

6. Give it a real address

   In Vault → Domains, either buy a domain inside Vaulter (it connects itself) or connect one you own 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.

Where to take it from here

• Email confirmations for every booking: the Resend guide.
• A Slack ping when a booking lands: the Slack guide.
• Real availability against your own calendar: the Google Calendar guide.
• Watch bookings convert: Analytics.