Home › Research › Hands-on test

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

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.

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.

T18 for Lovable was run on 26 September 2026. We connected GitHub with access limited to one empty repository; Lovable created its own repository with the full source and the database migrations, and committed no secret keys. Outside Lovable, on Node 22, the code installed and built without errors. It did not run on its own: the page loaded, but no classes did, because the database service key and the admin password stay inside Lovable. To move it you set up your own database from the migrations and take the bookings with you as the admin CSV (T14) or Lovable's full database export, which we did not trigger. T18 for Replit was run the same evening from the project's zip export on the free plan. It held the full source and its git history, but none of the data. Outside Replit the code installed and built with pnpm 10 (pnpm 12 refused) once two settings Replit normally supplies, PORT and BASE_PATH, were set, and it ran against a new, empty Postgres database of our own: the tables were created, a booking was accepted and counted, and the admin login refused a wrong password. One thing to know before you share or connect the code: the admin password the agent picked sits as a plain value in the project's .replit file and in its git history, so it goes wherever the export or a GitHub copy goes. Change it after exporting. For Emergent, T18 was checked in settings and documentation only.

What it took and what it cost

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

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.

Data, editions and corrections

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