
A date that could not move, so the scope did.
Tixoo is an event ticketing platform for India, built against a signed launch date. Most of the job was deciding what not to build, and writing down every change that moved money or time.
Role
Product and delivery lead
Timeline
2026, site live
Team
Two stakeholders, web and app developers, run by me
Live
tixoo.in ↗

01
The problem
Tixoo is a ticketing and live experiences platform for India. The agreement fixed an MVP launch date, and the scope behind it was everything a marketplace needs at once: a customer app on both stores, a promoter dashboard with a drag and drop seat map, an admin console, payments, QR entry at the gate, subscriptions.
Then a founding member marketing site was added on top, with three working days before its own launch. A weekend and a public holiday sat inside that window. Nothing about the date was negotiable, so everything about the scope had to be.
02
What I did
I cut the marketing site down to the one flow that had to work
The brief had five steps, a district level counter, an app preview and an interests picker. With only three working days, I took the funnel down to state, district, member, success, and got that signed off before anyone opened a file. The cut sections came back after launch, not before it.
I made the counter fake on purpose and put it in writing
The founding member count had to look alive on day one with nobody in it, and a real backend for that would have eaten the window. So I shipped a seeded front end counter with deterministic time based growth, which means it holds its value on refresh, and I wrote the decision into the shared document rather than leaving it to be discovered.
I held subscriptions out of the first store submission
Tixoo Plus runs on subscriptions, which have to be tested and released on Android and iOS together, and their Apple account was still migrating from personal to business. Submitting with it risked the review on both platforms, so it came out of the build and went back in as a paired release once the migration cleared.
I priced the post launch change list in developer days
When the change requests arrived, I split them into web bugs, web copy, web features, app bugs and the payment layer, put an effort figure on each, and showed the calendar estimate at two developers and at three. The conversation then stopped being about whether the list was reasonable and started being about how many people were on it.
The date was signed. The only variable left was what we agreed not to build.
03
How I ran it
There were two stakeholders and a launch date that had been signed, so every decision that moved money or time was repeated back to them as a written document rather than left in a chat. The agreement, the change request plan, the developer day estimate and the launch notes all exist as shared files.
I ran the web and app developers against that plan. The change list and the payments were tested together in one build rather than in pieces, because testing them separately would have hidden the interaction that actually mattered.
That's why the scope conversation after launch took one message instead of a week. Nobody had to remember what had been agreed.
04
The journey
The journey starts before the app does. Someone lands on tixoo.in, sees the events listing, opens an event, and finds the real seat pricing and a book button on the same page. How it works and the perks sit one level away, for the people who need convincing first.
Inside the product, the spine is discover, book and enter. Discovery and the event page carry the decision, Razorpay carries the payment, and the ticket resolves to a QR code that gets scanned at the gate. Tixoo Cash sits alongside as the balance a returning buyer spends from.
The promoter sees the mirror image of that, with a dashboard carrying the seat map and an admin console behind it, because a marketplace is really two products sharing one schedule. Subscriptions were deliberately held out of the first store submission and released as a paired Android and iOS build once their Apple account finished migrating.
05
What shipped
The founding member site went out on its date, and tixoo.in went on to carry the public site, with the events listing, individual event pages with real seat pricing, how it works, the perks and the policy set. The customer app was built to the signed scope with discovery, booking, QR tickets, Razorpay payments and Tixoo Cash, and the change list shipped as one tested build together with the payment layer rather than in pieces, so payments and the app changes were validated against each other. The store release sat with them.
06
Impact
Founding member site shipped to the signed date
On date
Working days to build and launch the site
3 days
Developer days scoped for the change list
22
Change list and payments tested together, not in pieces
1 build
07
The work
The app: finding an event, the tickets you hold, and checkout with the hold timer running. Then the public site: the events listing, a live event page with real seat pricing, how it works, the perks and the story.
08
Go deeper
Design system and Figma
The app and the promoter dashboard run off one type and colour set. The India map is built from real geographic data rather than an illustration, so all thirty six states and their districts are selectable and correct. The marketing site was designed and signed off in Figma first, precisely because the build window was too short to design inside it.
Build and handover
The customer app is Flutter, with web dashboards for the promoter and the admin, Razorpay for payments and RevenueCat for Tixoo Cash, and push notifications routed per event type. The store listings were created on their own accounts, and the repository transfers on settlement, which is written into the agreement rather than assumed.
More
All work
→








