Draftbit test data

The Fitting Room brief was pasted word for word (1,689 characters) into Draftbit's new-project screen on 27 October 2026, as a Mobile App (React Native with Expo, which also runs on the web) on the Blank template, with the default agent, OpenAI Codex with GPT-6.1 Sol, paid from the free starter credits. The clock stops when the app is live at a public address and the checks pass: 25 of 30 on the full scale, applied here as the 24 checks that could run.

The agent asked no questions. It built the whole app from the one prompt in 22 minutes and 34 seconds and used 1,534 credits. It built the timetable, the three roles, the booking rules, the admin tools and a Supabase database, and said that payments and emails would need keys from me.

The app was not live yet. Before publishing I had to set the production values for the database address and key by hand, deploy the database to production, publish, and then set the first admin in the database panel, because staff sign-ups need approval from an admin who does not exist yet. Publishing took 3 minutes. The app was live on its draftbit.dev address 43 minutes after I submitted the brief, and the checks passed 48 minutes after.

• The three hand steps (production keys, the database deploy and the first admin) are counted in the time and are not prompts. Draftbit's setup screens that came before the prompt took about 4 minutes and are counted too.

The written checks were run by hand on the published app, as a member, a coach (the role the app was later told to rename from instructor) and an admin. The six payment and email checks need my own Stripe and email keys, so the 30 checks become 24 and the thresholds apply in proportion.

All 24 checks passed: sign-up and log-in for each role, the reset email, the timetable with the three seeded classes, booking, My bookings, cancelling with the credit returned, the full-class rule, the coach's own classes and roster, attendance, the admin's class tools, every booking, the CSV, bookings per class, the Ask the studio form and the ten seed facts. Nothing was invented: the classes, prices, address, phone and email match the brief.

The booking window that opens over the timetable on a desktop and on a phone shows its text on top of the page behind it, so the words overlap. The booking still worked, so it is counted as a layout fault in the publishing test.

• The $24 single class is shown on the timetable and the passes page, but cannot be bought: checkout is switched off until Stripe keys are added. The booking and admin emails are saved in a queue and not sent; they are in the actions test.

Sign-up and log-in for a member, a coach and an admin, the reset email, then the two attacks from the brief run with the app's own requests from a second member's session, plus self-promotion attempts and the builder's own security scan.

Attack 1, a member asking for another member's booking by its id, returned an empty list; cancelling it returned a Booking not found error and deleting or changing it was refused by the database. Attack 2, a member calling the admin delete-class function, returned Admin access required. A member who tried to change their own role or credits, or to approve staff access, was refused.

Nobody can make themselves staff. A coach or admin sign-up creates a member with a request waiting; an admin approves it under Studio team. The first admin has to be set by hand in the database panel, because there is nobody yet to approve one. The reset email arrived within seconds and the app has a screen to set a new password, which then worked.

Draftbit's own security scan, run when the database is deployed, said Security checks failed with more than ten warnings that database functions can be run by signed-out or signed-in users. They are warnings, you can deploy anyway, and none of them gave my attacks a way in: each function checks the caller's role itself.

• The warnings were not all individually tested; I tried the member and admin actions and the staff approval. Draftbit's support was asked how it advises closing admin sign-up and has not answered.

The six data checks, run on the published app and in Draftbit's database panel: records are written; they survive a reload; they survive a republish; they survive a design change; the admin can view, filter, edit and delete in the tool; and records export as a file.

All six passed. Bookings, attendance, the Ask the studio message and sign-ups wrote real records to a Supabase database. After I republished the app as a new version, with the colour change and three other changes in it, every booking, credit balance and attended mark was still there. In the app the admin can view all bookings by status, edit and delete classes and read the studio inbox; the database panel lists six tables and lets an admin edit a row; the bookings export is a CSV with a row for each booking.

Deleting a class returns the credits of its bookings, and the app says so before you confirm. The database panel's SQL box is read-only on the production database, so a change there has to go through a row edit or through the agent.

• The Draftbit account holds one project with one Supabase backend, which is free during Draftbit's beta; what it will cost after the beta is not stated.

Publishing was done on the free plan to Draftbit's own address. Speed was Lighthouse mobile on the app's main page, three runs, on my own computer; layout was checked at 360, 768 and 1440 pixels. No custom domain, simulator, test build or store upload was tried: the first is a paid feature, and the others need a paid plan or accounts I did not open.

Publish worked on the free plan. The Publish menu publishes a web app to a draftbit.dev address in 3 minutes, with no paywall, and republishing took about the same. A custom domain, the iOS and Android simulators and test builds are not on the free plan: the menu shows a padlock on the simulators and test builds, and the pricing page lists the domain from Standard.

The three phone runs scored 57, 56 and 55. The largest paint took about 9 seconds on a simulated phone, the page weighs about 1.4 MB, layout shift was 0.07 and blocking time about 230 ms. There was no sideways scroll at any of the three widths. The booking and edit windows overlap their own text at phone and desktop width.

• Speed came from Lighthouse on my own Windows computer, which was busy, so the score may read a little low; Google's own PageSpeed service refused the request that day. No 100 seeded classes, no real phone and no domain.

The pricing page, the credit balance and the credit usage list were read on 27 October 2026 with a screenshot at each step. Draftbit charges a plan fee and sells AI credits separately.

The Free plan cost nothing and needed no card. It gave 3,000 credits, once, that expire after a year. The first build used 1,534, the colour change 204, the phone field 386, the role rename 421 and the About page 278: 2,823 in all, with 177 left. I stopped there, because the next change would have taken me close to zero and the sign-in screen says extra charges apply when credits run out. Draftbit sells credits from $5 at 1,000 credits a dollar, so what I used is worth about $2.80.

Standard is $15 a month, or $12 a month billed yearly, and Pro is $30 a month. Standard adds code export, GitHub export, custom domains, store publishing and 15 builds a month; Pro adds the simulators and test builds. Paid plans use your own Claude or ChatGPT subscription or API key for the agent, with no weekly cap, or credits you buy. At the rate I measured, a build and all twelve changes would need about 5,400 credits, roughly $5.40, so the free allowance covered about half of the test. I did not read what 1,000 bookings a month would cost.

• The cost for the remaining eight changes is an estimate from the four I ran. Yearly prices were read but no checkout was opened.