A booking screen that subtracts one from a number can still oversell the final seat. Before building, write the states and tests that decide whether a prototype is safe enough for a controlled pilot. This guide uses a fictional six-seat workshop and makes no claim that PickByTask tested a live Lovable app.
Lovable currently describes building applications from plain-language instructions and provides backend and integration routes. Its Supabase documentation covers connected database workflows. These capabilities support prototyping; they do not prove that generated booking logic is correct or secure. Lovable product information
Contents — jump to a section
Define the record before the screen
For each workshop, record a stable session ID, capacity, confirmed count and status. For each request, record a unique request ID, attendee, session, state and created time. Suggested states are pending, confirmed, cancelled and rejected. Decide which state consumes a seat before prompting the builder.
Use Lovable for a disposable booking prototype, then prove capacity and cancellation rules with test accounts before connecting real customers or payments.
Copy a bounded build prompt
Create a prototype for one fictional workshop with capacity 6.
Each booking request must have a unique request ID.
Only confirmed bookings consume capacity.
Never confirm when confirmed_count is already 6.
Repeating the same request must not consume another seat.
Cancellation releases one seat once; repeating cancellation changes nothing.
Show an error when the save fails. Do not display a success message first.
Use fictional names and no payment or real customer data.The prompt states expected behaviour, but it is not a database guarantee. Review the generated schema, access rules and server-side operation with a qualified developer before production. Lovable's Supabase documentation explains the current connection route; configuration remains the builder's responsibility.
Visit Lovable ↗Run six capacity cases
- Start with zero confirmed bookings. Submit one request and verify the count becomes one.
- Submit the same request ID twice. The second attempt must return the existing result without increasing the count.
- Begin with five confirmed bookings and send two different final-seat requests as close together as possible. Exactly one may confirm; the other must be rejected or waitlisted.
- Cancel one confirmed booking. Capacity should increase once. Repeat the cancellation and verify it does not increase again.
- Simulate a failed save or lost response. The screen must show an unresolved state and allow safe retry without creating a duplicate.
- Try reading and changing another test user's booking. Both actions must follow the intended role rules.
Record the starting state, action, expected result, actual result and database rows after each case. A green confirmation screen alone is insufficient evidence.
Decide whether the pilot can continue
The fictional example passes only when confirmed bookings never exceed six, duplicate requests remain single, cancellation releases one seat, and a failure cannot show false success. Reset the test database and rerun the suite after every change to schema, authentication or booking logic.
If the final-seat test fails, stop accepting requests. Use a manual waitlist with timestamps while a developer fixes the atomic capacity check. If role separation fails, remove shared access and keep the prototype on fictional data. Payments, refunds, legal notices, privacy, abuse controls and operational monitoring require separate review before launch.
Product and Supabase documentation were inspected on 26 September 2026. This is a test plan, not a production-readiness or security certification.