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

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.

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

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

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:

Cursor, Codex and Gemini CLI read the same skills, because a skill is just a folder with a SKILL.md. Clone 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:

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

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 and the booking-site playbook 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:

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.

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

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.