All BlueprintsCommerce
Event ticketing with door check-in
Tickets for one event: they sell until the allocation runs out, every seat carries its own code, and the door admits each code once, whatever the signal is doing.
What you’ll build.
A ticket shop and a door scanner. People buy tickets until the event sells out, and each gets their own code even if somebody else paid. On the door a phone scans that code and says let them in, says already used the second time, and keeps working where there is no signal.
What you’ll learn.
Each sprint is built around one skill. You show you have it in a pull request your team reviews, then explain it in a walkthrough.
Authentication
You can register and sign in a user, keep a request authenticated without asking for the password again, and explain where the credential lives in the browser and why there rather than somewhere else.
Stock that cannot go negative
You can decrement stock on a sale and prove that a hundred simultaneous orders for ten items produce ten sales and ninety refusals.
Notifications people do not mute
You can notify a user when an event concerns them, show an unread count that survives a refresh, and honour a preference that says stop.
Roles and permissions
You can give users different roles and have the server refuse what a role may not do — not merely hide the button — and show the refusal working against a request the interface never offered.
An order that moves through states
You can move an order through its states, refuse a transition that should not happen, and show the history of how it got where it is.
Background jobs
You can hand work to a worker, tell the user it is in progress, and show the result when it lands — and say what happens to that work if the process dies halfway.
Realtime updates
You can push a change from the server to an open page and have a second browser see it — and say what happens to a client that was disconnected while it changed.
Going live
Somebody who has never met you can open a URL and use the product — and you can say what is different about the copy running there, where its secrets come from, and what you do when a release turns out to be wrong.
The roadmap. 8 sprints, 40 tasks.
Every sprint has a goal and a set of tasks. Open a sprint to see the tasks you will pick up.
Accounts, and borrowed phones
Somebody can make an account, and a phone signed in for one night stops being signed in.
4 tasks
- A buyer can register and land signed in
- Signing back in survives a week away
- Organiser and door accounts exist, and cannot be self-issued
- A venue phone can be signed out from somewhere else
Putting an event on sale
An event goes on sale with a fixed allocation, and sells out at exactly that number.
5 tasks
- An organiser can put an event on sale
- A buyer can find an event and see what is left
- A buyer takes up to six tickets in one go, or none at all
- Three hundred buyers and a hundred tickets produce a hundred sales
- Selling out is a state of the product, not an error
A code of their own
Every seat sold reaches the person who will use it, carrying a code nobody can guess.
6 tasks
- Every seat in a sale gets its own code
- A code cannot be worked out from a code you already hold
- A buyer can pass a ticket to whoever is using it
- A ticket opens on a phone with no account and no signal
- An organiser can issue a ticket nobody bought
- A ticket link that no longer means anything says so
Working the door
Somebody on the door scans a code and gets an answer they can act on without reading.
5 tasks
- A doorkeeper can scan a code and admit somebody
- Only the people working this door can admit anybody
- The answer is readable at arm's length in the dark
- A doorkeeper picks the event they are working
- A ticket is found by name when the phone is dead
Once, and only once
A code admits its holder exactly once, and two phones scanning it together produce one admission.
5 tasks
- A second scan of the same code is refused, with a time and a door
- A ticket can only take the steps that make sense
- Two phones scanning one code at the same instant admit one person
- A doorkeeper can undo an admission they made by mistake
- Every scan leaves a record, including the refused ones
When the signal drops
The door keeps scanning with no connection, and what it sends afterwards is counted once.
5 tasks
- The door keeps answering with no connection
- Scans made offline reach the server when the signal returns
- The same scan arriving twice is one admission, not a refusal
- A code admitted twice offline is surfaced, not hidden
- The doorkeeper can see what has not been sent
Taking a ticket back
A ticket taken back stops working at the door, and the organiser watches the count without pressing anything.
5 tasks
- An organiser can take a ticket back, and the seat goes back on sale
- A ticket that was taken back is refused, with its own reason
- A phone that was away catches up before it admits anybody
- The organiser watches the count climb from the back of the room
- A refund and a scan in the same second have one winner
Somewhere a stranger can reach
The product is on the internet at its own address, the door works at the venue, and a bad release can be undone while people are queueing.
5 tasks
- A stranger can buy a ticket without the developer's laptop
- Every value the product needs comes from where it runs
- Ticket messages genuinely leave and arrive
- The door works on a phone at the venue, camera and all
- A bad release can be undone while people are queueing
Read before you build. The best engineers do.
Senior engineers read the docs before they touch the code. Every Blueprint comes with short documents on the product and its world, the kind a team hands a new hire. Read them well and you ask sharper questions and walk into every review prepared.
What you are building
One event, two products sharing a database, and the one promise the whole thing rests on.
The ninety minutes at the door
Domain you will not have: queue rates, venue wifi, volunteers, comps, and why the door is a different product from the shop.
More commerce Blueprints.
Corner shop storefront
A small shop sells online. The shelf shows what is genuinely there, a basket survives the tab it was made in, the shop never takes money for a tin it does not have, and the buyer can follow their order until they pick it up.
Food ordering with options
Ordering for one restaurant, where a dish is a set of choices rather than a price. A size replaces the base price, extras add to it, some extras only exist on some sizes, and the total the customer is charged is worked out from what they chose rather than taken from the browser.
Restock waitlist
A waiting list for what a small shop has run out of. People ask to be told when it returns, and when three come back the stock goes down the line in the order they asked: held long enough to act on, offered to nobody behind them until that window closes, and never offered to the same person twice.
Build event ticketing with door check-in.
Start your free week. Adaeze runs your kickoff, and Lars reviews every pull request.