One data model to rule the event

Go to any large event and count the systems: one company sells the tickets, another runs the gates, a third does cashless payments, a fourth tracks staff, a fifth reports on all of it after the fact. Five vendors, five databases, five formats, and every handoff between them loses information. The gate has no idea what you paid. The wallet has no idea where you are. Whoever writes the post-event report gets to reconcile all of it by hand.

Building Vizha, I wanted the opposite: one platform where a ticket, a tap at the gate, and a wallet payment are the same record in the same data model.

Type safety is the architecture, not a feature

The only way I know to keep one data model honest across a web dashboard, three mobile apps, and a hardware ingest pipeline is to make disagreement a compile error. So Vizha is a Turborepo monorepo with end-to-end types: a NestJS + tRPC + Drizzle API, and every client (the Next.js web dashboard, plus the Expo attendee, vendor, and staff apps) consumes the same typed contract. Change a field on the server and the mobile app stops compiling, which is exactly what I want it to do.

The gate is just another writer

I didn't treat the RFID gate reader as a special integration. It's just another client that writes access events into the same model over MQTT, using the same @identium/reader SDK that powers my desktop apps. A tap is a row. So is a payment, and so is a position update. Once everything lives as rows in one model, the "analytics" everyone pays a fifth vendor for turns out to be a query.

What this buys you

• No reconciliation. There's one source of truth, so there's nothing to reconcile.
• Offline tolerance in one place. The scan queue that survives a dead venue network gets written once instead of once per vendor.
• A product, not an integration. You can actually design the whole experience, because for once you own the whole stack.

It was more work up front, no question. Every month since, it's been less.