Solution · Barbershop booking
A booking app for your barbershop, calendar and confirmations included
Describe the booking flow you want and get a working app — a calendar customers book into and an email confirmation sent on every appointment, all wired up for you.
For anyone · describe it → live, hosted app
At a glance
Is this the right pattern for you?
The short version, before the detail — who this is written for, what you start from, and what exists at the end.
| This solution | |
|---|---|
| Written for | Anyone who can describe what they want |
| You start from | A sentence describing the thing you want to exist |
| You end up with | A live, hosted application on a real URL |
| The path runs | Scope → build → preview → refine → Go Live |
| Built on | Prompt to app · Managed backend · Live preview · Go Live |
| Plan needed | Free to build and preview · Starter for a custom domain |
No timings are quoted anywhere on this page, because how long a build takes depends entirely on what you asked for.
The challenge
Why this is usually hard
Worth understanding before the how — because the reason this is difficult is not the reason most people assume.
A booking app is the first thing most small service businesses want and the first thing that turns out not to be a website. A form that collects a name and a preferred time is easy. A booking system is not, because it has to hold state: appointments have to be stored somewhere durable, a slot that is taken has to stop being offered, and the customer has to receive something that proves the booking happened.
That is three separate pieces of infrastructure — a database, application logic, and a way to send mail — before any of it looks like a barbershop. The two usual answers are both unsatisfying. Building it yourself means standing up Postgres, choosing an email provider, and maintaining the whole thing forever. Renting a booking SaaS means paying every month to work the way that product thinks a shop works: its idea of services, its idea of buffer time, its idea of what a deposit is.
The interesting constraint is that shops differ in exactly the details the rented product will not bend on. Two barbers who share a chair. A beard trim that only one of them does. Fifteen minutes of clean-up after a colour. This pattern is worth understanding because the flow is described rather than configured, so those details are things you state in a sentence instead of things you work around.
How it works
From a sentence to a live app
Every stage in order, including the ones that happen without you asking.
- 1
Describe your services, your barbers and your hours
A booking app for my barbershop with a calendar and email confirmationsName the people who cut, list the services and how long each one takes, and give your opening hours. This is the part a rented booking product makes you fit into its own fields; here it is a sentence, and the app is shaped around it.
- 2
Settle the scope in chat first
BlueprintA new project opens in chat before any tabs appear. The agent asks the questions it cannot guess — who signs in, what gets stored, whether money changes hands — and builds a blueprint from your answers. For a booking app those answers matter a lot, because they decide whether you get a public booking page, a staff view behind sign-in, or both. The build starts when you confirm the blueprint.
- 3
A real data layer is written for you
Appointments have to live somewhere durable, so the Postgres schema, the migrations and a vetted access layer are written into the project when the app needs to store data, and you connect the Supabase project they run against. It is a standard Postgres database, which matters: your bookings and customers stay in a format you could query, export or take elsewhere.
- 4
The calendar and the booking rules get built together
Open slots are offered, booked slots stop being offered, and each appointment is written to the database as it is made. The calendar is not a decorative widget on top of a form — it is reading the same data the confirmations are sent from.
- 5
Shape the flow around how the shop actually runs
promptAsk for a "choose your barber" step, buffer time between cuts, a service that only one person offers, or a cut-off so nobody books ten minutes before closing. Click into the calendar in the preview to adjust it directly instead of describing where you mean.
- 6
Confirmations send themselves
Transactional email is already connected, so a confirmation goes out the moment a booking is made. Because the plumbing is there rather than pending, adding a reminder the day before is a follow-up sentence and not a second integration project.
- 7
Add a deposit if no-shows are the real problem
Stripe checkout can be wired in so a slot is only held once a deposit is paid. This is the honest fix for empty chairs, and it is available on the Pro plan. If no-shows are not your problem, you leave it out and nothing about the app is shaped around payments.
- 8
Go Live
Go LivePublish to a real hosted URL customers can book from, over HTTPS, and connect your own domain from settings on a paid plan when you want the address to carry the shop name.
Why code-anything
What you get out of the box
Not a feature list — the specific things this pattern removes from your side of the work.
A calendar backed by real data
Customers pick an open slot and it is written to the database as they book. Taken times stop being offered, so the double-booking problem is solved by the data model rather than by you watching a shared inbox.
Appointments you own
Postgres on Supabase holds every booking, customer and service, reached through a data-access layer written into the project rather than hand-rolled. Standard Postgres means your history is real, queryable data rather than rows locked inside somebody else’s product.
Confirmations without a mail server
Each booking triggers a confirmation through managed transactional email. Reminders, cancellation notices and a note to the shop can follow the same path, because the sending is already wired rather than waiting on a signup.
Deposits when you need them
Stripe checkout can be added so a booking is only held once a deposit clears — the standard remedy for no-shows on a busy chair. Payments are included from the Pro plan.
A private side for the shop
Authentication is part of the managed stack, so a staff view of the day’s appointments can sit behind sign-in while the booking page stays public. You are not sharing one link and hoping nobody finds the admin screen.
The rules can change as the shop does
A new barber, a new service, different hours in summer — each is a sentence, not a support ticket to a booking vendor and not a migration. The app is yours to reshape.
In practice
What it looks like
Read the prompt closely and notice how much of it is business detail rather than technical instruction: who cuts, how long a cut takes, when the shop is open. That is the spec.
The three things that make it an application rather than a form — somewhere to store the appointment, logic that stops a taken slot being offered again, and mail that confirms it — are produced as part of the same build. You did not choose a database, and you did not sign up to send email.
A booking app for my barbershop with a calendar and email confirmations.
Two barbers, 30-minute cuts, open Mon–Sat 9–6.
Customers pick a barber and a time, and get an email when they book.✓ built a calendar with bookable 30-minute slots
✓ wrote the Postgres schema and data layer for appointments and customers
✓ wired confirmation emails to fire on each booking
✓ running in the live previewWhat you ship
- A booking calendar that offers open slots and stops offering taken ones
- A managed Postgres database holding every appointment, customer and service
- Automatic confirmation emails on each booking, with reminders a sentence away
- Booking rules that match how your shop actually runs, not a vendor’s defaults
- Optional Stripe deposits on the Pro plan when no-shows are costing you chairs
- A live hosted URL customers can book from, and your own domain on a paid plan
- A real application you can keep reshaping as the shop changes
What it involves
The honest shape of the path
Stage by stage: what the platform does, and what is genuinely still asked of you.
| Stage | What actually happens | What is asked of you |
|---|---|---|
| Scope | A new project opens in chat before any tabs appear. The agent asks about the parts it cannot guess and fills in a blueprint. | Answer the questions and confirm the blueprint. Nothing is permanent — you can change anything after the first build. |
| Build | The agent plans the work, writes the code and runs it, reaching for the data, auth, email or payments bricks only where the app actually needs them. | Nothing. You can pick a build quality — Prototype, Standard or Best — if you want fewer checks or more review. |
| Preview | A live preview mirrors the real running app, updating as it takes shape. | Look at it properly, including at phone width. This is where problems are cheapest to catch. |
| Refine | Click an element to target an edit, describe the change in chat, or attach a screenshot as a reference to match. | Judgement. This is the part that is genuinely yours, and pointing beats describing. |
| Go Live | The same app you previewed is published to a public URL over HTTPS on managed hosting. | One decision, plus a domain if you want one. Custom domains are included from the Starter plan upwards. |
The path is short because the writing, hosting and deploy steps are not yours to make. The time this takes depends on what you are building, so no page on this site quotes a number.
Describing an app and refining it in the live preview starts on the Free plan, which includes one active project and a managed database, auth and email. Publishing to your own custom domain is included from Starter upwards, and payments are a Pro-plan capability. See the full plan comparison.
What you own
What you are left holding
The thing this pattern produces is an application, not a document inside a builder. That distinction is easy to skip past and it decides what your options look like a year from now — so it is worth being concrete about what exists at the end.
What exists when you are done
- A real codebase, running on managed infrastructure rather than rendered inside a proprietary editor
- A live, public URL served over HTTPS on Cloudflare, with a custom domain available on a paid plan
- A managed Postgres database on Supabase if your app stores anything — standard Postgres, so the data stays queryable and portable
- Authentication, transactional email and payments already connected where the app calls for them
- A version history of build checkpoints on Repository → Changes that you can rewind to
What stays in your hands
- The next change is the same conversation as the first one — no separate CMS and no developer to book
- Nothing is written in speculatively, so a simple page stays a simple page
- A rewind snapshots the current state before it runs, so trying something is not a one-way door
- The preview is the app that ships — there is no export step and no gap between what you approved and what visitors get
FAQ
Common questions
Keep looking
Other reference patterns
Every solution is a worked end-to-end example. If this one is not quite your situation, one of these probably is.
Bakery website
Describe your shop in plain English and watch a real website build itself in a live preview — complete with a contact form that emails you every enquiry.
For anyoneStripe dashboard
Describe the numbers your team cares about and get a private dashboard — revenue, growth and customers — with sign-in, built without touching a line of code.
For anyoneOr the other way of working — connect a repository and get changes as reviewed pull requests:
Add dark mode
Connect your GitHub repo and ask for dark mode. The agent indexes the code, makes the change in a sandbox, verifies it builds, and opens a pull request for you to review.
For developersFix failing tests
Connect your repo and point at the broken test. The agent reproduces the failure, finds the cause, fixes it, re-runs the suite green, and opens a pull request.
For developersJS to TypeScript
Connect your repo and name the components to convert. The agent adds real types, fixes the fallout, verifies the build, and opens a pull request you can review.
For developersBuild booking app the way it should have been.
Start free. A managed database, authentication and transactional email come wired in, and Go Live puts the app you previewed on a real URL.