building RevoTickets

Summary

Revolution Stage puts on live theatre and music in Malaysia, and they needed a way to sell reserved seats for their own shows without handing a cut and their audience data to a third-party platform. RevoTickets is that: a bilingual (English and Malay) storefront that sells numbered seats, takes payment through the local bank rails, and hands over a scannable entry pass. I own the product and the build. The interesting part, for a project-management write-up, is that this got built the way a much larger team would build it, by one to two people leaning hard on AI, and the discipline that made that possible is worth more than any single feature.

Here is what it looks like today, on a laptop and on a phone.

What it had to do

A ticketing platform sounds like a solved problem until you write down the list. Model a real hall, seat by seat. Show it to a buyer who is choosing where to sit, and keep that map honest while other people are grabbing seats at the same second. Take money through FPX, which is how Malaysians actually pay online, and survive that gateway going quiet mid-transaction. Issue a wallet pass. Let door staff check people in from a phone. Do all of it in two languages, and do it as a proper multi-tenant system so more than one organiser can run on it later.

None of those are hard on their own. The job was getting all of them to stand up together and stay standing while the requirements kept moving. The event page below is the middle of the funnel: pick a show, read the synopsis, go choose seats.

Shipped in waves, behind a gate

The method that made a small team move like a big one was boring and strict: break the work into small waves, plan each wave in writing before touching code, review it, and then lock the result behind an automated gate so it could never regress. Every wave left the product shippable. Nothing sat half-finished on a branch for a month.

The timeline it actually took

The heavy building happened across 2026, in overlapping tracks rather than a tidy single file. Language coverage and a framework upgrade came first, then the seat-map foundation and the design-system re-skin ran alongside the venue and booking work, and the public storefront got its own revamp near the end. The chart below is the shape of it.

A fair caveat on the numbers, because the Work section is for honest facts and not sales copy: the repository was started from a Bullet Train template years earlier, so a raw commit count includes inherited history and overstates the bespoke work. The delivery intensity is real though, and the peak-week figure is the part I would stand behind: 134 commits in seven days is what a deadline looks like.

The seat map, a project of its own

The single biggest line item was the seat map, and it earned that. It is not one screen, it is a builder for staff to lay out a hall, a preview, a live buyer view, and the engine that draws them all from the same source. It went through its own set of plans (seat identity, a serializer, real-time updates, roles, then a cutover) before it was trustworthy. If you want the gory detail of how a right-to-left row keeps its aisle in place, that is the first post in this series. Here is the buyer's-eye result, on both screens.

What is under the hood

For a sense of the surface area one or two people were keeping in the air, here is the count as it stood mid-year. An independent bottom-up estimate put a from-scratch rebuild of this at roughly 1,700 hours of work.

Ninety-six controllers, seventeen background jobs, a fistful of service objects, thirty Stimulus controllers on the front. It is not a small app pretending to be big. It is a real one that a small team kept honest with tests and gates.

What got cut, and why that mattered

The most useful project-management work on RevoTickets was deciding what not to build. A launch date only exists if you are willing to move things off the near list, and we moved plenty. The organiser analytics dashboard, the people merge-and-invite flows, and the in-app help centre were all split out of the design-system re-skin so it could actually finish, rather than sprawling until it never did. A planned move to self-hosted infrastructure got deferred whole, with only the one piece that a nearer feature needed pulled forward. The hall builder shipped English-only on purpose, because translating an internal staff tool that only a handful of people use was not worth holding a launch for.

Every one of those was written down as a decision with a reason, not lost in a backlog. That is the difference between deferring something and dropping it.

The road ahead

RevoTickets is pre-launch as I write this, and it is not vapour: it has already sold real seats to real Revolution Stage shows through the checkout described in these posts. The plan from here is staged, roughly six milestones over two years, each one a fundable chunk rather than a wishlist. The near one is the only one with a date I would defend.

What I took from it

• Waves beat sprints of heroics. Small, shippable slices behind an automated gate let a tiny team move fast without leaving a mess to trip over later.
• Write the decision down. "We are deferring X because Y" in a plan file is worth ten times the same thought lost in a chat, because future-you argues with the reason, not the vibe.
• A launch date is a scope decision, not a calendar one. The near milestone shipped because things were taken off it, on purpose, with reasons.
• Be honest about the numbers. Inherited history inflates a commit count, an internal tool can stay one-language, and a plan is not a promise. Saying so costs nothing and buys trust.

If the single-problem deep dives are more your thing, the three posts below pull apart the seat map, the payment path, and the seat-selling race one at a time.