Case studyVenua
Co-founder and sole engineer of an event platform. At IdeaLab! 2026 it ran applications, payments, door scanning, the attendee app and email for 820 tickets.
Co-founder & engineer, 2025 – today, updated
What Venua is
Venua (formerly InnoCom) is event software for B2B organisers: it helps them earn more from sponsors and exhibitors with measurable leads, booked meetings and ROI reports. My co-founder runs sales and partnerships; I build everything else: the web apps, the native apps, the backend and the infrastructure.
Four events, one platform
Each event pushed the platform one step further.
| Event | What ran on our stack |
|---|---|
| IdeaLab! 2025, WHU | A networking web app (PWA). Ticketing stayed with an outside vendor. |
| Young Founders Conference, Nov 2025 | Native iOS and Android apps, an admin, and matching based on LLM-enriched profiles with explainable compatibility scores, delivered by a matchmaker bot in chat. |
| Q-Summit 2026, Mannheim | A native iOS app and a FastAPI backend for 1,111 attendees: 70% used the app, workshops filled to 99.5% on average, and 96.7% of answered connection requests were accepted. |
| IdeaLab! 2026, WHU | The whole event: applications, payments and invoices, door scanning, iOS and Android apps, email workflows, push, and an organiser API. |
IdeaLab! 2026: running a whole conference
- Checkout and applications on Next.js: card saved at application, charged only after reviewer approval, with idempotent webhooks, a reconciliation job and German VAT invoices.
- Admin and event CRM with role-based access, saved views, an email workflow editor, push campaigns, and a door scanner that keeps working offline.
- Attendee app for iOS (SwiftUI) and Android (Kotlin and Compose): swipe-based matching for people, jobs and workshops, chat, agenda, reminders and wallet passes.
- API in FastAPI with an outbox queue for push and notifications.
What the event measured:
- 660 of 763 conference tickets checked in, with 0 wrong admissions and a median door-scan round trip of 0.25 s.
- 553 people used the app, 74% of ticket holders; 93% of Day 1 users came back on Day 2.
- 1,545 messages between attendees. The 2025 networking tool at the same conference produced one.
- 7,527 of 7,527 queued notifications delivered, and 0 crash restarts over the event.
Not everything went right. One deploy during the busiest hour cost a burst of failed requests, and CI silently ran zero steps all week because of a billing block. Both are guarded now.
The 2.3-second click
Staff opening a record in the admin waited 1.8 to 2.8 seconds on a frozen screen. SQL was not the problem: queries ran in under a millisecond. I profiled the live app with Playwright, cold cache, three to four runs per measurement, and found three causes stacked on top of each other: the server functions ran in a US region against a database in Frankfurt, auth re-resolved the session on every request, and the record page made sequential round trips five levels deep.
| Measurement | Before | After |
|---|---|---|
| Open a CRM record | 1.8 – 2.8 s, frozen | 0.8 – 1.3 s, skeleton at about 0.8 s |
| First paint, dashboard | 1.2 – 2.2 s | 0.4 – 0.8 s |
| First paint, CRM list | 1.5 – 2.3 s | 0.4 – 0.7 s |
The fix: move the functions next to the database, cache the session cookie for five minutes while still checking permissions on every request, run independent reads in parallel, and stream skeletons. A Playwright test failed against the old build and passed after. It is a small sample from one network path, but the before and after use the same method.
533 individually written emails, each one fact-checked
After the event every attendee got a personal recap email, written for them rather than from a template. Each email involved two AI agents:
- a writer with read-only access to that one person's data, which had to list every claim it made with its source;
- an independent verifier that re-fetched the data, traced every claim, checked the layout at three widths, and was the only one allowed to send.
A send-once ledger blocked duplicates. Before the real run, a canary with deliberately planted errors went through the pipeline, and the verifier caught both. Result: 533 of 533 delivered, 0 bounces, 0 complaints, 0 duplicates.
How I work on Venua
Most of the code is written by AI coding agents that I direct. My part is the architecture, the evidence each change has to produce, and the calls that matter. During event week we kept shipping, including features that went live on Day 1. Agents are what made that pace possible; independent checks are what made it safe.
