Bolt.new test data

The Fitting Room brief was pasted word for word (1,689 characters) and submitted at 22:30 UTC on 25 October 2026. The clock stops when the app is live and 20 of the 24 checks pass, which is the published 25 of 30 in proportion once the six payment and email checks are left out. Every prompt and its tokens are in the ledger.

Bolt.new asked two design questions (look and logo), which I skipped. Version 1 was saved at 22:43 UTC, about 12 minutes after the submit, using about 1.3 million tokens. I published from the chat in under 2 minutes.

The first version was broken. The landing links pointed at /login and /signup/member, which are not routes, so sign-in sent visitors back home (fix F1, about 0.1 million tokens). The admin Instructors page crashed with React error 301 (F2). Booking could never work because the database function used a SQL lock that Postgres rejects with an aggregate (F4). The admin All bookings page and CSV were empty and the member counters and coach roster were wrong (F5). F3 was a test-only prompt that gave every member 5 credits.

After F5 at 23:55 UTC (1 hour 25 minutes after the submit, six prompts of which one was test-only) 23 of the 24 checks passed. The one that cannot pass is the password reset link.

• The first publish took under 2 minutes and the version 1 clock reads 22:43 UTC against a 22:30 submit.

The 24 checks that need no keys of my own were run against the live app, by hand and by script, with a screenshot per check. The six payment and email checks (C24 to C29) are left out because they need your own Stripe and email keys. The inbox check was read by hand. I also counted anything the brief never asked for.

The final app passed 23 of 24. The one that failed is C03: the password reset link goes to localhost.

All ten seed facts were correct. Inventions: a "Most popular" tag on the pass, "Monday through Saturday timetable" wording and stock photos from Pexels.

The timetable shows a weekly pattern with day tabs, not dated classes.

• Counts before the five fix prompts were not recorded as a total.

Sign-up, log-in, log-out and password reset for a member, a coach and an admin, then two attacks on the live app with the wrong session. Requests and responses are saved as transcripts.

Sign-up worked for two members, the admin (with the single-use first-admin code Bolt.new printed in the chat) and the coach (with an invite code made by the admin). A session survived a reload. The reset email, from Supabase Auth, arrived in 11 seconds, but its link goes to localhost, so no new password can be set on the published site (the SITE_ORIGIN secret was never set).

Attack 1 was blocked. Member A reading the bookings, profiles, credits and orders tables through the app's own API got only A's own rows; B's profile by email returned an empty list; the admin tables (messages, invite codes, email log) returned empty lists.

Attack 2 partly succeeded. A member's class edit and delete returned 200 with no rows changed, so they were blocked. But PATCH profiles with {role: admin} on the member's own row returned 200 and the role became admin. I restored it afterwards.

• Bolt.new's security audit (in the Publish dialog) was not run.

Six checks: the form and bookings write real records; they survive a reload, a republish and a design change; in Bolt.new's own data panel I viewed rows, filtered, added a row, deleted it, and exported as CSV and JSON.

All six passed. The contact form and bookings wrote records. In the panel the classes table showed its 5 rows, the filter worked, an added row saved, and deleting it brought the count back to 5. Export as CSV downloaded with every column and Export as JSON was offered. After the twelve changes all five classes were still there, with the Power Reformer capacity of 4 from change 5.

• Record and storage limits were not read.

The twelve scripted changes, one at a time, each one message. After each change I published with Update and ran a short check of the member, admin and coach screens. The tokens and minutes are in the ledger.

All twelve finished in one message each and the short check passed after every one. Change 5 (Power Reformer capacity 4) was only a data edit and saved no new version. Change 8 (a second email when the admin cancels) could not be checked, because the app sends no emails without keys of my own. Change 7 planted a bug and the next message fixed it.

The twelve used about 3.4 million tokens. Dark mode used the most, about 0.9 million.

• A full re-run of the 30 checks after every change was not done.

Publish from the chat, then update after each change; Lighthouse mobile three times on the home page.

The first publish finished in under 2 minutes at fitting-room-pilates-4xkg.bolt.host, with no extra cost. Each later change needed the Update button; one update took 241 seconds.

Lighthouse mobile (version 13.5.0): 79, 78 and 77, median 78; largest paint 4.1 to 4.7 seconds, layout shift 0, blocking time 0 ms, about 511 KB in 11 requests.

The Publish dialog offers a custom domain and a security audit. I did not use either.

• Only the home page was measured; layout faults, a real phone and add to home screen were not.

Project menu, Download; unpack in a clean folder, install the dependencies, build, and read the code for anything that only works on Bolt.new.

The Download item gave a zip of 66 files (754 KB) on the second try; the first attempt showed no file. It holds a Vite and React project with react-router, a supabase folder with the database migrations and three edge functions (checkout, booking emails and the payment webhook), and a .env file with two Supabase values.

A search of src and supabase found no Bolt-specific package or reference. npm install and npm run build ran clean on my computer, building in 3 seconds. To run it elsewhere you need your own Supabase project, the migrations applied, the three functions deployed and the two values set. I did not read Bolt.new's terms.

• Not run end to end against my own Supabase project; the terms were not read.

Prices were read on bolt.new/pricing on 26 October 2026. The token ledger priced the whole test at the plan's rate: 10 million tokens for $25 a month.

The whole test used 5.5 million of the 10 million monthly tokens (the build 1.3, five fixes 0.8, twelve changes 3.4). At $25 per 10 million that is about $13.75, and the first working version about $5.25.

Unused tokens roll over one month and then expire (the meter said 25 December 2026). What happens at the limit was not tested. The next plan is $50 a month for 26 million tokens.

Stripe and email fees are separate and were not measured.

• Limit behaviour and the free plan's limits were not read.