One booking app. Three AI builders. Here is what actually worked.

Name: Hands-on test of three AI app builders on one booking-app prompt (September 2026)
Creator: AIBuilder Marketplace
License: https://creativecommons.org/licenses/by/4.0/

On the morning of 26 September 2026 we gave Lovable, Replit and Emergent the same prompt for a small class-booking web app, on each one's free plan, and then tested what they built against 18 checks we wrote down before the first build. Where a check failed, the builder got up to three repair prompts, always in the same words. This is one run per builder: a case study, not a ranking.

When ten people tried to book the last spots of an eight-person class at the same moment, only Lovable's first version stopped at eight. Replit's and Emergent's first versions accepted all ten, and Replit's public schedule then went blank. Both were fixed after we described the failure, Replit in one repair prompt and Emergent in two.AIBuilder Marketplace, hands-on test, 2026-09-26. Free to quote with attribution.

3AI app builders, free plans, same prompt, same morning

18checks, fixed before the first build

2 of 3first versions let 10 people book 8 spots

1 of 3could publish and stay online on the free plan

Who pays us. Replit and Emergent run affiliate programmes we are part of: if you sign up through a link in our reviews of them, we may be paid. Lovable does not pay us. There are no affiliate links on this page. Daan also uses Replit for a separate project of his own; this test used a new, empty free account so that his paid plan and history played no part.

The prompt

Sent as the first and only message to each builder, word for word:

Build a web app for a one-person yoga studio to take class bookings.

Requirements:
1. A public page shows the classes for the next 14 days: Monday to Friday at 07:00 and 18:30, Saturday at 09:00, no classes on Sunday. Each class has 8 spots and shows how many spots are left.
2. A visitor books a class by entering a name and an email address. The number of spots left goes down by one. A class with 0 spots left cannot be booked.
3. After booking, the visitor sees a confirmation with a unique link to manage the booking.
4. Through that link the visitor can move the booking to another class that still has spots, or cancel it. Cancelling frees the spot.
5. The same email address cannot book the same class twice.
6. An admin page protected by a password shows all bookings per class, lets the admin cancel any booking, and has a button that exports all bookings as a CSV file with the columns: class date, class time, name, email, status.
7. Bookings are stored in a database and are still there after a page reload and after the app is republished.
8. Publish the app at a public URL.

Do not add payments, email sending or user accounts.

Small enough for a free plan, but it contains the things that separate a demo from something a studio could use: a hard capacity limit, a private link, a protected admin page, an export, and data that has to survive a redeploy. Payments and email were left out on purpose, because they need accounts with third parties and would have made this a test of those services instead.

How we tested

Same start. Three new free accounts, prompts sent between 12:11 and 12:14 Amsterdam time, default mode in each builder (Replit's only option on the free plan is its "Free" agent mode; Lovable in Build mode; Emergent as a web app). When a builder asked questions, we let it decide for itself.
Prompts only. We did not touch the code. Clicks on a builder's own buttons (create project, publish) were allowed and are recorded below.
Tested on the published app, or on the preview where publishing was not possible. Test data was made up (example.com addresses).
The simultaneous-booking check sent ten booking requests for one empty class through each app's own booking endpoint at the same moment, then counted the bookings that existed afterwards. We also checked the same thing one booking at a time; all three passed that.
Repairs used one template for every builder: “These tests fail: [test, what we did, what we saw]. Fix only these, change nothing else, and republish.” Maximum three per builder.

Results, check by check

First version, and where it changed, the result after a repair prompt.

Check	Lovable	Replit	Emergent
T01 Published at a public URL	Pass	Partialmanual Publish click; free deployments expire	FailDeploy needs a paid plan
T02 14-day schedule, 8 spots	Pass	Pass	Pass
T03 Booking lowers the count	Pass	Pass	Pass
T04 Confirmation with private link	Pass	Pass	Pass
T05 Full is full (10 at once)	Pass8 accepted, 2 refused	Fail10 of 10 accepted, schedule went blank → Pass after repair 1	Fail10 of 10 accepted → still failed after repair 1 → Pass after repair 2
T06 No double booking	Pass	Pass	Pass
T07 Move a booking	Pass	Pass	Pass
T08 Cancel frees the spot	Pass	Pass	Pass
T09 Link cannot be guessed	Pass	Pass	Pass
T10 Admin needs the password	Pass	Pass	Pass
T11 Password not visible in the browser	Pass	Pass	Failin the CSV export URL → Pass after repair 1
T12 Admin overview per class	Pass	Pass	Pass
T13 Admin can cancel	Pass	Pass	Pass
T14 CSV with the five columns	Pass	Pass	Pass
T15 Rejects bad input	Pass	Partialname of only spaces saved → Pass after repair 1	Partialname of only spaces saved → Pass after repair 1
T16 Data survives a republish	Pass	Pass	Not testedcould not publish; see below on deleted data
T17 Usable at 390 px	Pass	Pass	Partialpage 494 px wide → Pass after repair 1
T18 Code and data export	Not testeddocs: GitHub sync on all plans	Not testedaccount export available on free	Not testedGitHub integration from Standard

T18 was checked in each builder's settings and documentation only. Connecting GitHub needs an authorisation we did not give for a test account, so no code actually left any of the three.

What it took and what it cost

	Lovable	Replit	Emergent
Plan and mode	Free, Build mode	Starter (free), Free agent mode, Power and Max locked	Free, web app
First working version	about 10 minutes	8 minutes of agent work (Replit's own count)	about 9 minutes to a preview
Repair prompts needed	0	1 (2 minutes)	2 (about 5 minutes each)
Credits	4 of the 10 on a new account	not shown on the free plan; daily allowance used up after repair 1	19.17 for the two repairs (34.66 to 15.49)
Publishing on the free plan	one click, stays online, “Edit with Lovable” badge	manual Publish click; “Free deployments are temporary and will expire”; “Made with Replit” badge	not possible: Deploy opens the plan chooser ($1 seven-day trial, then $20 a month)

Emergent's balance rose from 10.00 to 34.66 during the first build without any purchase, and the app does not show why, so the cost of its first build cannot be stated. Lovable's new account started with 10 credits (five daily plus five that expire on 26 September 2027), not the five a day its pricing page leads with.

What each builder did

Lovable

Asked two questions of its own: whether to create a project from the chat, and whether to publish. After that it built, published and tested its own flows (booking, double booking, moving, cancelling), deleted its test booking and told us what it had assumed: an invented studio name, a temporary admin password and Amsterdam time.

It was the only one whose first version held the capacity limit under simultaneous bookings. It also checked input on the server, not only in the form, and prefixed CSV values that start with = + - or @ so a spreadsheet does not run them as formulas. Nobody asked for that.

Replit

Built a separate API and web app on PostgreSQL, ran its own functional pass and reported everything green. It did not publish: “Replit requires the final Publish action”, so a person has to press the button.

Its self-test booked one at a time. Ten at once got all ten in, after which the class list endpoint returned an error and the public page said “No classes on the calendar yet” until two bookings were cancelled. Told exactly that, it added a database lock per class in two minutes and got it right. The free daily allowance was gone after that one repair.

Emergent

Asked five clarifying questions (we let it choose), used a separate design agent and a testing agent, and suggested extra features at the end. Its first version overbooked, put the admin password in the export URL, saved a blank name and did not fit a phone screen.

The first repair fixed three of the four, but while “clearing test data” it dropped the entire bookings collection, which deleted all our test bookings and also the index its capacity fix relied on. The second repair added a lock and passed. It deleted all bookings again while cleaning up. On the free plan the app could not be published at all.

Choose for your situation

One run per builder on one day does not support a winner, so this is what the run does support.

You want something online today without paying. In this test only Lovable published on the free plan and stayed up without a timer.
You already pay for Replit Core. Replit fixed its failure fastest once the failure was described precisely. Budget for the paid plan: on Starter the usage meter is hidden and one repair used the day's allowance.
You like a builder that asks and tests. Emergent did the most asking and the most self-testing, yet its own tests reported success on a capacity fix that did not hold. You will need a paid plan to publish, and you should keep your own copy of your data.
Whichever you pick: test the case of two people booking the last spot at the same moment. All three passed one-at-a-time booking; two of three first versions failed the simultaneous case, and none of their own test reports said so.

Check the evidence

Date and plans: 26 September 2026, 12:11 to 14:20 Amsterdam time; free plans as listed above, prices read the same day on each vendor's pricing page.
The apps: Lovable's app (stays online), Replit's app (a free deployment that Replit says will expire). Emergent's only exists as a preview that sleeps when idle. All three contain our made-up test bookings.
The data: every check with what we saw, every prompt with its time, and the credit readings are in results.json (admin passwords removed).
What this is not: one run each, so a builder could do better or worse on another day or another prompt. Not a security audit: we checked two simple things (the private link cannot be guessed, the password is not in the page) and nothing deeper. Not a load test: ten requests, not thousands. Not a production test: no real payments, emails or traffic.

Our full reviews: Lovable · Replit · Emergent. How we separate researched reviews from hands-on ones: how we review.

Citation

AIBuilder Marketplace, “One Booking App, Three AI Builders: What Actually Worked”, hands-on test run on 2026-09-26. Free to quote and reproduce with attribution (CC BY 4.0).