Co-founder & CTO · Live · private codebase · Dec 2025 to now
tunyt
tunyt runs an event from start to finish: finding the venue, selling tickets, coordinating vendors and keeping the day on schedule. Organisers usually do all of this in a spreadsheet.
- Sign-ups
- 10K+in the first month, no marketing
- Paid ticket buyers
- ~3,000
- Team
- 6 people, 4 in techI lead the tech team
- Recurring hosts
- Coding Blocks LPU, Trendians, Seen Kya Hai
- Weekly requests
- 69K to 485K
- Latency
- 110 ms to 59 ms
- Apdex
- 0.55 to 0.89
- Error rate
- 2.84% to 0.32%June to August 2026, in production, while traffic grew
- Deploy time
- 20+ min to under 9 minDocker layer caching, lint and tests as parallel jobs, model weights baked into the base image
My part
I'm the CTO and I built the technical side: the agent workflows, the real-time infrastructure and the interface. I decide the architecture, lead hiring, and lead a tech team of four out of six people. We build the mobile app, the web app, the AI infrastructure and the design at the same time.
How it works
Several agents work together, one each for booking, ticketing, vendors and the running order. Tixin handled ticketing before tunyt existed. tunyt covers everything around it.
Making it faster
I measured first and then fixed what the traces showed. Traffic kept growing the whole time.
When the database saturated in July 2026, I treated it as a system problem instead of a slow query. That meant a connection budget split between the API and the workers, capped fan-out, single-flight caching for expensive reads, and daily rollups for analytics.
What went wrong
On 1 May 2026 I moved our queue sweepers into the worker startup code. That started 21 separate runtimes at once on one node. CI passed. About thirty seconds after the deploy, production was down. I wrote up what happened.