Adventure World
A branded ticketing website for an events business whose events draw thousands of people. It replaces a ticketing marketplace that charged 12% + $1.25 per ticket; ours is priced at 3.5% + $0.50, about 69% less, and the client keeps its own brand and customer list.
| When | Mar 2026 – |
|---|---|
| Role | Signed the contract myself; now built under Stelta. Top contributor on a team of 3. |
| Stack | TypeScript, React, Node.js, PostgreSQL, Redis, Stripe, Azure, Cloudflare |
| Highlights |
|
| Links |
Why it exists
Adventure World sold tickets through a ticketing marketplace. The marketplace took 12% plus $1.25 of every ticket, checkout carried the marketplace’s brand instead of theirs, and the customer list lived on the marketplace. They wanted their own website and their own customer data.
I won the contract myself in March 2026 as an independent developer. Other nightlife businesses saw the demo and asked for the same thing, so in September 2026 I started Stelta with two partners, and the project moved under it. Stelta owns the platform and licenses it to each client.
The site is still being built and hasn’t launched. The 69% figure compares our planned price with what the client pays now.
What it does
Buyers browse events, pick a ticket type (some need a password, and some need the host’s approval), pay on the page, and get a ticket with a QR code that they can also send to a friend by phone number or email. Door staff scan the codes at the entrance. The organizer can issue refunds, manage door staff, and see where buyers come from and where they drop out of checkout.
Nothing about Adventure World’s brand is built into the server, so the same system can run other clients’ sites, each with its own look.
The hard parts
Never selling the last ticket twice
When two people try to buy the last ticket at the same moment, a simple “check how many are left, then reserve one” can let both of them through, because both checks happen before either reservation. I made the check and the reservation one single step inside Redis, which handles one request at a time, so only one buyer can get it. A reservation expires if the buyer doesn’t finish paying.
Payments, including tickets that need approval
Most tickets are paid for normally through Stripe. For events where the host approves each buyer, the card is only held, and it’s charged once the host says yes. Money goes straight to the organizer’s Stripe account, minus our fee. If Stripe’s confirmation that a payment went through arrives late or never arrives, a background check catches it, so nobody pays and ends up without tickets.
Background tasks that are safe to repeat
Sending tickets, refunds, transfers and notifications all run as background tasks. When something fails, a task can run again, so every task is written so that running it twice has the same effect as running it once. Nobody gets two refunds or two copies of a ticket.
Fixing what heavy traffic exposed
We sent heavy test traffic at checkout. Afterward I cut the number of trips checkout makes to the database and to Redis, cached event pages, and gave background tasks their own database connections so they can’t slow down buyers. Two problems only appeared under load, one with how long idle connections stayed open and one with a task log that grew without limit. Both are fixed.
Rate limits
To stop one person or bot from flooding the site, each user or address gets a limited number of requests. The count is kept in one shared place, so every server enforces the same limit.
Analytics
The organizer can see where buyers come from, such as Instagram or a tagged link, and where they drop out of checkout. I record this with MetricHouse, my open-source library.
Who built what
I built the foundation the team builds on. My two partners work on top of it, from phone verification to screen designs and page flows. I wrote about 84% of the backend code and about 94% of the project’s documentation and coding rules.