tunyt
Your city's event passport
Alpha v0.1
tunyt
Your city's event passport
Every event collapses the same way — not from a single disaster, but from a thousand tiny coordination failures that stack faster than any team can fix them. The problem was never effort. It was architecture.
Picture this: it's T-minus 40 minutes to doors. Your co-organizer is fielding a "how do I get in" DM on Instagram. Someone's Excel RSVP sheet isn't matching the printed list. A volunteer just texted saying they'll be 20 minutes late. The payment link you sent to late registrants is throwing an error. And your keynote speaker just asked if you could "set up the screen" — which apparently wasn't confirmed with anyone.
None of these are catastrophes on their own. Together, they are your event.
This is the part of event management nobody talks about when they're selling you ticketing software or a Notion template. The chaos isn't the exception. It's the load-bearing wall. And every tool currently on the market was designed to handle exactly one room of it, while the rest of the building catches fire.
The modern event stack is genuinely impressive if you look at it from 30,000 feet. You've got dedicated tools for registrations, ticketing, check-in, email blasts, team coordination, payment collection, post-event surveys. Each one is polished. Each one has a great landing page. Each one has exactly zero idea that the others exist.
The last line is the one that matters. In every event stack, there is always one integration that runs on human anxiety — someone who wakes up at 3am the night before to make sure the RSVPs are reflected in the check-in list, that the payment statuses are correct, that the QR codes actually work. That person is not a bottleneck. They're a single point of failure wearing a volunteer badge.
And when something goes wrong — and something always goes wrong — the resolution time is measured not in seconds, but in how fast you can reach the right person on WhatsApp.
The event management industry isn't unsophisticated. It's over-sophisticatedly fragmented. The tools got better, and the coordination cost stayed exactly the same — just hidden inside Slack threads, spreadsheet tabs, and calendar reminders nobody set.
Here's what actually breaks at events, in order of how often it breaks:
Context doesn't travel. When someone RSVPs and answers a custom question ("dietary preference: vegan, session track: product"), that context lives in your form tool. It doesn't automatically know to flag this person at check-in, or route them to the right breakout room, or appear in your post-event follow-up. Every handoff between tools is a moment where context dies.
State is always stale. "How many people have checked in?" is a question that should have an instant answer. Instead, it requires someone to look at two different tools, subtract a number, and text you back. This is not a data problem. It's an architecture problem.
Decisions are made by hand under pressure. Waitlist triggered? Someone has to decide who to let in, message them, update the list, and re-run the numbers. All in real-time, at the door, while also checking people in. This is not a time management problem. This is a workflow that was never automated in the first place.
The tools didn't fail you. The space between the tools failed you. And nobody's been building in that space — because it's unglamorous, it's workflow-layer work, and it requires understanding events at the operational level, not just the software level.
The framing that's been missing is this: an event is not a form. An event is a system. It has state. It has actors (organizers, attendees, volunteers, speakers). It has decision points. It has real-time feedback loops that should close automatically.
When you think about it that way, what you actually need isn't better software in any one category. You need an OS — something that understands the whole system, connects every surface, and makes decisions at machine speed when the situation calls for it.
The difference isn't features. It's that the system understands what an event is, and every surface — RSVP, team, QR check-in, online, custom questions, payments — is a view into the same underlying state machine. When one thing changes, everything knows.
There's a version of this argument that sounds like "AI will run your events." That's not the claim. The claim is more specific and, we think, more interesting: the decisions that are made by hand today are mostly not decisions at all — they're lookups.
"Is this person on the list?" That's a lookup. "Has this QR code already been used?" That's a lookup. "Who's next on the waitlist?" That's a lookup. "Did the payment go through?" That's a lookup. The organizer isn't making a judgment call when they answer these — they're running a query against a data source that isn't connected to anything, by hand, under time pressure, while someone is waiting at the door.
Agentic systems handle lookups. They handle the predictable, rule-based, high-volume decisions that eat organizer bandwidth at the worst possible moments. What's left — the judgment calls, the relationship moments, the on-the-fly pivots when the keynote runs 20 minutes over — those remain entirely human. And they're better, because the human isn't context-switching between a spreadsheet and a payment dashboard to answer a question that a machine should have answered before anyone asked it.
We've run events. We've been the person refreshing the RSVP sheet at 2am. We've been on the team WhatsApp at T-minus 10 minutes trying to figure out if the QR scanner app was showing the right data. We've exported from four tools, opened three spreadsheets, and still not had a clean headcount when the room was half-full.
The thing that struck us wasn't that the tools were bad — most of them were fine, individually. It was that nobody had built for the system. Nobody had asked what it would look like if the entire operational surface of an event lived in one place, with state that actually flowed between surfaces, and with intelligence at the workflow layer that could close decision loops without a human in the middle.
That's what tunyt is. Not a ticketing tool. Not a registration form. An agentic OS for event management — where every event type (RSVP, ticketed, team, online, custom) runs on the same real-time state, and the organizer gets their attention back for the work that actually matters.
The event is always already running — in the sense that complexity doesn't wait for you to get organized. What tunyt does is make the system fast enough that you're always ahead of it. Not catching up. Ahead.
We're just getting started. But if you've ever been the person holding five tools together with sheer force of will the night before an event — this one's for you.
RSVP, ticketed, team, online, or custom — one platform, real-time state, no spreadsheets.
Get started free →