Retail
Service bookings for a bike shop
A bike shop books services by type with different workshop times, tells the customer when the bike will be ready, and notifies them by text when it is done. The mechanic sees the queue for the day and records extra parts used.
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 bike shop books services by type with different workshop times, tells the customer when the bike will be ready, and notifies them by text when it is done.
Section 03 · Screens
Every screen, and what it is for.
- ›Customer Booking — customer books service slot, selects bike type, picking the time slot instantly.
- ›Mechanic Queue — mechanic views daily job list, updates status, and logs extra parts instantly.
- ›Shop Dashboard — shop manager views revenue, active workshop workload, and technician hours instantly.
- ›SMS Dispatcher — system sends automated completion texts to customer numbers instantly.
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.
service_type
id uuid, name text, base_duration_minutes int, base_price numeric(10,2), active boolean
Access · Public read for active types, authenticated shop staff read/write all.
appointment
id uuid, service_type_id uuid, customer_name text, customer_phone text, bike_description text, scheduled_start timestamptz, estimated_completion timestamptz, actual_completion timestamptz, status enum(booked,in_progress,ready,completed,cancelled)
Access · Customers read their own appointments by phone lookup, shop staff read/write all.
extra_part
id uuid, appointment_id uuid, part_name text, cost numeric(10,2), added_at timestamptz
Access · Shop staff read/write; customers read parts attached to their appointment.
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
booked → in_progress → ready → completed | 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.
SMS delivery failure leaves customers stranded at closing time.
Log delivery status from Twilio webhooks and display failed notifications visibly on the mechanic queue.
Concurrent mechanic updates on the same appointment overwrite extra parts.
Use database row-level locking and append-only part logs tied to appointment IDs.
Section 08 · Deliberately left out
What version one does not do.
- ×Customer account login — passwords add friction; use magic links via phone number if needed later, making v1 faster to ship.
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.
- Which SMS provider gateway do you currently use for messaging?
- Should shop staff be able to manually override estimated completion times calculated from service types?
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.