# Build a booking website with AI: Lovable, v0, Base44, Claude Code and Cursor

> Lovable, v0, Base44, Claude Code, Cursor or Bolt: connect any of them to Opencals and the booking site your AI builds takes real bookings and payments.

URL: https://opencals.com/blog/build-booking-website-with-ai
Author: Stanislav Tyshchenko
Published: 2026-09-26
Updated: 2026-10-25
Categories: announcement, tutorial

Ask an AI app builder for "a booking site for my physio clinic" with nothing else to go on, and it has to invent a backend. You get a lovely page, a grid of times that lives in a hard-coded array, and a form that writes a row to a table. It looks finished. Then two people book Tuesday at 10:00, nobody's card gets charged, and the physio's actual calendar has no idea any of it happened.

That isn't the builder's fault. Availability across staff and rooms, holding a slot while someone types their card number, timezones, deposits, refunds: that's a booking engine, and a booking engine is exactly the part you don't want generated fresh on every prompt.

So I did the opposite. Opencals already runs that engine behind a public API. What was missing was a clean way to hand it to the tools people actually build with now. There's now a documented setup for the app builders I get asked about most, **Lovable**, **v0** and **Base44**, and the same knowledge loads into coding agents like **Claude Code**, **Cursor** and **Codex** as Agent Skills. The builder designs the site. Opencals does the booking.

> **Key takeaway**
>
> To build a booking website with AI, let the AI build the screens and give it a booking API for everything that has to be right. With Opencals that means a custom connector in Lovable, the open-source agent skills in v0, Claude Code, Cursor or Codex, or a backend function plus two skills in Base44. The generated site then reads your real services, shows live availability, holds slots in a cart and takes payment through your own Stripe account. Setup takes about ten minutes per builder, and you can build and test everything on a free development store, which runs in test mode until you switch it to production.

## The builder does the design, the API does the booking

The split is the whole idea, so it's worth being precise about it.

Your AI builder owns everything a visitor sees: layout, typography, the hero photo, the service cards, how the slot picker feels on a phone. Change your mind about the colour scheme ten times; nothing breaks. It also owns the _shape_ of the flow, which matters more than people expect: a barber books a person, a padel club books a court on a grid, a car rental books a range of days. The [seven booking flow shapes](https://opencals.com/blog/booking-flow-examples) are written up separately, each with a prompt.

Opencals owns everything that has to be right: which services exist and what they cost (you manage those in the dashboard, not in code), which times are free for which staff member or court, holding a slot for ten minutes while checkout happens, discounts and promo codes, tax, the Stripe payment into your own connected account, the confirmation and reminder emails, and the order and invoice afterwards. Every booking lands in the same dashboard as bookings from anywhere else.

The builder never writes availability logic. It calls endpoints and renders what comes back. That's also why the setup below is mostly about giving the AI good instructions, and not about writing code.

## What you hand the AI

Each builder gets the same knowledge in the shape it can read:

- **An API reference.** Every storefront endpoint, the fields that matter, the order to call them in, and the mistakes worth avoiding: bookable IDs are variant IDs, slot times are UTC, the checkout `customer` object needs a `kind`.
- **A booking-site playbook.** How to pick the flow for the business (a salon books a person, a padel club books a court, a yoga studio sells spots in a class), which pages to build, what the slot picker and checkout need, and a checklist to run before calling it done.
- **The key, somewhere safe.** Your storefront key goes into the builder's secret store, never into generated frontend code.

For Lovable those are two knowledge files on a connector. For v0, Claude Code, Cursor and Codex they're the [open-source Opencals agent skills](https://github.com/letsopencals/skills). For Base44 they're two workspace skills plus a small backend function.

There are also two things an agent can read on its own, without any setup: the docs as plain Markdown through [llms.txt](https://opencals.com/docs/llms.txt), and a docs MCP server at `https://opencals.com/docs/mcp`, which lets Claude, Cursor or any MCP client search the documentation and the OpenAPI spec while it works.

## Pick your builder

|                           | How Opencals connects                           | Where the key lives         | What it generates                                    |
| ------------------------- | ----------------------------------------------- | --------------------------- | ---------------------------------------------------- |
| Lovable                   | Custom connector + 2 knowledge files            | Connector credentials       | React + server functions                             |
| v0                        | Agent skills from skills.sh                     | Environment variable        | Next.js + Opencals SDK                               |
| Base44                    | Backend function + 2 workspace skills           | App secret                  | React + Deno backend function                        |
| Claude Code               | Plugin with both skills, plus the docs MCP      | Environment variable        | Next.js from an official template, or your own stack |
| Cursor, Codex, Gemini CLI | Skill folders copied into the project           | Environment variable        | Whatever stack the project uses                      |
| Bolt, Replit              | API reference + playbook pasted as instructions | The builder's secrets store | Depends on the builder; no tested guide yet          |

The full setup for each app builder, with every field ready to copy:

- [Lovable: add Opencals as a custom connector](https://opencals.com/blog/lovable-booking-system): Six form fields, two knowledge files, one API key. Every Lovable project in the workspace can use it.
- [v0: attach the Opencals skills](https://opencals.com/blog/v0-booking-website): Add letsopencals/skills, set one environment variable, describe the business.
- [Base44: backend function and skills](https://opencals.com/blog/base44-booking-app): One secret, two workspace skills and a first prompt that builds the proxy.
- [Prefer code? Start from a template](https://opencals.com/open-source): Eight MIT Next.js booking sites on the same API: salon, barber, clinic, padel club, car rental, language school, villas, Pilates.

If you don't have a favourite yet: v0 gives you the most portable result of the app builders, because what it generates is a normal Next.js app using the Opencals SDK, so you can take the repo and keep going in Cursor or Claude Code. Lovable is the quickest to get looking good, and once the connector exists nobody in the workspace touches a key again. Base44 makes sense if your team already lives there. If you're a developer who already works in an editor, skip the app builders and use Claude Code or Cursor directly.

## Claude Code, Cursor and Codex: install the skills once

Coding agents don't need a connector. They need to know the real method names and call order, and that's what the two skills carry: `opencals-storefront-api` for any code that talks to the API, and `opencals-build-booking-site` for standing up a whole site from the closest template, rebranding it and deploying it to Vercel.

In Claude Code, the skills install as a plugin and trigger on their own when you ask for anything booking-related:

```text
/plugin marketplace add letsopencals/skills
/plugin install opencals@opencals
```

Cursor, Codex and Gemini CLI read the same skills, because a skill is just a folder with a `SKILL.md`. Clone [letsopencals/skills](https://github.com/letsopencals/skills) and copy the two folders into wherever your tool keeps skills or rules; the location differs per tool and changes often enough that I'd check its docs rather than trust a path from me.

Then, optionally, connect the docs MCP server so the agent can look things up instead of guessing. In Claude Code:

```bash
claude mcp add --transport http opencals-docs https://opencals.com/docs/mcp
```

In Cursor, add it to `.cursor/mcp.json`:

```json
{ "mcpServers": { "opencals-docs": { "url": "https://opencals.com/docs/mcp" } } }
```

It exposes two read-only tools: a search across the docs, and a read of any docs page or the OpenAPI spec. It reads documentation; it doesn't make bookings or touch your store.

Put the key in `.env.local` as `OPENCALS_API_KEY` (a private `spk_` key, used only in server code), and give the agent the business, not the mechanics: "Build a booking site for a two-location physio clinic in Leeds, calm and clinical, deploy to Vercel." With the build skill loaded it picks the clinic template, wires it to your store and restyles it.

## Bolt, Replit and builders without skills

Not every builder reads skills or offers a connector. For those, the setup is manual but short: paste the [API reference](https://opencals.com/ai/opencals-storefront-api.md) and the [booking-site playbook](https://opencals.com/ai/lovable-booking-site-playbook.md) into the project's instructions or knowledge, store the key in the builder's secrets, and tell it to call Opencals only from server-side code.

I'll be straight about this one: I haven't written or tested a dedicated Bolt or Replit guide yet, so I can't promise the same hit rate as the three builders above. The files are the same ones Lovable uses, and they're written to be read by any model. If you try it, the test-booking checklist below is what tells you whether it worked.

## The first prompt matters more than the builder

Whichever you pick, the prompt that works best describes the business, not the booking system. The instructions you gave the AI already cover how booking works. What they can't know is who's booking what:

```text
Build a booking website for Northside Physio, a two-location physiotherapy
clinic in Leeds. Services and prices come from Opencals. Patients pick a
location first, then a treatment, then a physio or "anyone", then a time.
Calm and clinical: white, soft blue, lots of space. Pages: home, treatments,
booking flow, checkout, confirmation.
```

Notice what's missing: no list of services, no prices, no opening hours. Those come from the store, so when the clinic adds a treatment in the Opencals dashboard it shows up on the site without anyone prompting again.

The playbook steers the flow by business type, which is where generated booking sites usually go wrong. A padel club should get a courts × time grid and a 60/90-minute length picker, not a list of "services" with a staff dropdown. A class-based studio should get a timetable with "4 spots left", not a one-to-one appointment form. If your business is one of those, start from the matching prompt in [booking flow examples](https://opencals.com/blog/booking-flow-examples).

## Where it still needs you

Four things I'd rather you hear from me than find out after launch.

**A free store can't take real money.** Every Opencals store starts as a free development store, forever, with no card needed. It's perfect for building, and the whole checkout works in Stripe test mode. To take real payments you switch the store to production, which is when pricing kicks in (pay as you go from $0 per month, or a monthly plan when the volume justifies it; see [pricing](https://opencals.com/pricing)).

**AI output still needs a test booking.** The instructions are good, but the builder writes new code every run. Before you share the link, book something end to end: pick a time, apply a promo code, pay with a Stripe test card, and check the booking appears in your dashboard. Each tutorial ends with the short checklist I use.

**Gateways share a rate limit.** Behind Lovable's gateway every visitor arrives from the same IP, so a Lovable site gets about 120 API requests a minute in total. Fine for a salon, tight on launch day. The playbook tells the model to cache the catalogue and use availability ranges for calendars, and it's worth checking the generated code actually does.

**Opencals isn't open source.** The agent skills, the SDK and the Next.js templates are MIT-licensed. The booking engine they talk to is a hosted service. If you need to self-host the engine itself, this is the wrong tool, and Cal.com or Easy!Appointments are better places to look.

## Why this matters more than another booking widget

Most booking tools give a business the same hosted page everyone else has, with their logo in the corner. The alternative used to be hiring a developer to build against an API.

AI builders removed most of the cost of that second option. A salon owner, an agency or a developer on a Sunday afternoon can now describe the site they want and get something that looks like theirs. What those builders can't safely generate is the commerce underneath: the carts, payments, discounts, rescheduling and invoices. Opencals is that part, and now you can plug it into the builder or agent you already use.

If you build something with it, send it my way. I'd like to see what people make, and the first few sites will shape what goes into the skills next.

## Frequently asked questions

### Can AI build a booking website that takes real bookings?

Yes, if the AI builds the front end and a booking API handles availability, slot holds and payment. Connect Opencals to Lovable, v0, Base44, Claude Code or Cursor and the generated site reads live services and availability, holds the slot in a cart and takes payment through your own Stripe account. Without a booking backend, AI builders usually produce hard-coded times and no real payment.

### Do I need to know how to code?

No. The app-builder setup is copy and paste: form fields, two text files and an API key. The AI builder writes the code. Knowing how to read an error message helps when you test the first booking.

### Which AI builder works best with Opencals?

All of them can build a working booking site. v0 produces a standard Next.js app on the Opencals SDK, which is the easiest to take elsewhere. Lovable's custom connector keeps the key out of every project once an admin has set it up. Base44 fits teams that already build there. Developers who work in an editor get the most control from Claude Code or Cursor with the Opencals skills.

### Is it free to try?

Yes. An Opencals development store is free with no time limit and runs payments in Stripe test mode. You pay only after switching the store to production to take real bookings. Each builder has its own plan requirements; Base44 needs a Builder plan for backend functions and workspace skills.

### Can Claude, Cursor or ChatGPT read the Opencals docs directly?

Yes. The docs are published as Markdown with an llms.txt index at opencals.com/docs/llms.txt, and there's a docs MCP server at https\://opencals.com/docs/mcp that Claude Code, Cursor and other MCP clients can connect to. It searches and reads the docs and the OpenAPI spec; it doesn't make bookings.

### Where do bookings from the AI-built site show up?

In your Opencals dashboard, next to bookings from every other channel. Orders, invoices, confirmation emails and reminders work the same way as on the hosted booking page.

### Can customers pay by card?

Yes. Checkout returns a Stripe client secret for your own connected Stripe account, and the generated page renders Stripe's payment form. The builder never needs a Stripe secret key. Cash, bank transfer and free bookings work too.

### Does it work with Bolt or Replit?

Probably, but I haven't tested a dedicated guide for either yet. Paste the Opencals API reference and booking-site playbook into the project instructions, keep the key in the builder's secrets, and call the API only from server code. Then run one test booking end to end before sharing the site.