Fitness
Memberships and door access for a gym
A gym sells monthly memberships that renew by card. Members open the door with a QR code from their phone, and access is refused automatically when a payment fails. The owner sees who is in the building and which memberships lapse this month.
Automatically generated draft
Written by machine against our own engineering playbook. The company is invented; the decisions are the ones we would make on a real build. A reviewed blueprint goes further — nine sections, agreed line by line, and it is what the build is tested against.
Section 01 · What has to work
A member's successful monthly payment must automatically and immediately grant them QR code access to open the gym door.
Section 03 · Screens
Every screen, and what it is for.
- ›Member: Access QR Code — A member opens it to show their QR code; the code must load instantly.
- ›New Member: Sign Up & Pay — A new customer creates an account and starts a membership; payment confirmation is key.
- ›Owner: Live Access Log — The owner sees a reverse-chronological feed of all entry scans (granted or denied).
- ›Owner: At-Risk Memberships — The owner views members whose payment failed or card is expiring soon.
Anything not on this list is not in version one. That is what keeps a fixed price fixed.
Section 04 · The data model
What it stores, and who can read a row.
user
id uuid, email text, name text, role enum('member', 'owner'), payment_provider_customer_id text
Access · A user can read their own row; an owner can read all.
membership
id uuid, user_id uuid, status enum('active', 'payment_failed', 'cancelled'), price_cents int, next_billing_on date
Access · A user can read their own membership; an owner can read all.
access_event
id uuid, user_id uuid, timestamp timestamptz, result enum('granted', 'denied')
Access · The owner can read all events; a member can read their own.
Those access rules belong in the database, not in the screens. Someone who edits the address bar still cannot read a row that is not theirs — and the test that proves it blocks delivery if it fails.
Section 05 · States
pending_first_payment → active ↔ payment_failed → cancelled
Most scope arguments three weeks into a build are really arguments about a state nobody named at the start.
Section 06 · Where this breaks
What bites products like this one.
The door scanner loses internet connectivity, blocking valid members or admitting lapsed ones.
The reader must operate in an online-first mode, falling back to a cached list of active members that is minutes old.
A member screenshots their QR code and shares it with a friend for free access.
The QR code will be a short-lived token that refreshes in the app every 30-60 seconds, invalidating prior codes.
A payment run fails midway due to a third-party outage, leaving member statuses inconsistent.
Billing jobs must be idempotent and resumable, with alerts triggered if the failure rate exceeds a set threshold.
Section 08 · Deliberately left out
What version one does not do.
- ×The 'who is in the building' view — it requires tracking exits, not just entries, doubling hardware and state complexity.
This is the section that protects the date, and the only place in the document where somebody says no. It is also why clients trust the rest of it.
Still open
What we would ask before quoting.
- What specific hardware will be used for the door scanner and what are its technical capabilities?
- Is there any grace period after a failed payment before access is denied, or is termination immediate?
- What is the workflow for a member to update their credit card details?
Half of this already exists
Renewal Engine
The billing half of this is a solved problem: recurring charges, a retry ladder on failed cards, access cut and restored automatically.
It is one of our pre-built products: the code is handed over to you, adapted to your own wording and rules, and the rest of the specification above is built on top of it rather than from scratch.
Your product, not this one
Get this written for what you are actually building.
Describe it in a sentence and the generator returns the same sections for your own product. Free, no email, nothing saved to a list.
Next step
Find out if your idea fits in 10 working days.
Tell us what you want to build. We reply the same day with a straight yes, no, or here is what we would cut.