Lovable, v0 and Base44 can now build booking sites that take real bookings

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. As of this week there's a documented setup for the three I get asked about most: Lovable, v0 and Base44. 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.

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 they're the open-source Opencals agent skills, the same ones that work in Claude Code and Cursor. For Base44 they're two workspace skills plus a small backend function.

Pick your builder

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

If you don't have a favourite yet: v0 gives you the most portable result, 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.

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.

Where it still needs you

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

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