Social Events & Ticketing Platform
A social platform where hosts run events, sell tickets and extend the product with plugins — from the app, the web, or an AI assistant.
The product's name is omitted here at the company's request — no client names or screenshots. I'm a founding team member; the architecture, decisions and outcomes below are first-hand.
A US social-tech startup set out to fix a painfully common failure: most casually planned meetups never actually happen. The product began as a consumer app for personal events and grew into a B2B platform for organizations, venues and promoters. I joined as a founding engineer and became the architect for that growth — the plugin system, the ticketing and seating inventory, the organization model, and the public API that now also serves AI assistants through MCP.
7+
Major product initiatives led end to end
3
Surfaces in one monorepo
React Native app, web app, serverless backend
~60%
Logic shared across surfaces
Types, constants and helpers in shared packages
99.9%
Uptime through peak event weekends
Serverless backend scales with demand
- Role
- Senior Software Architect & Founding Lead
- Timeline
- Jul 2023 – Present
- Type
- Full-time · US startup
- Scope
- Architecture, mobile, web, backend, public API, MCP server
Stack
Chapter 01
Where it started
The problem the product exists for is social, not technical: people want to see each other, and the plans die in the logistics. Organizing even a casual gathering meant juggling group chats, spreadsheets, payment apps and calendar invites — and every tool handoff lost a few attendees. Platforms that could handle the logistics were built for conferences, too formal for a birthday dinner; the informal tools couldn't take payments or manage a guest list. Most planned meetups simply never happened.
The first version of the app served individuals hosting personal events, and it worked. Then growth arrived from somewhere else: organizations. Clubs, venues, promoters and membership communities wanted to act as a brand, bill members monthly, sell assigned seats and run recurring programming — needs an individual host never has.
Every one of those needs touched the same core objects (users, events, tickets, payments), and each team wanted to ship its feature without waiting on the others. Without a deliberate foundation, the codebase would have forked into special cases — an 'org events' module bolted beside 'personal events', two checkout paths, two notification systems, drift everywhere.
At the same time, hosts kept asking for one-off features: a speed-dating matcher, a donor wall, a promoters wall. Each was genuinely valuable to the event that wanted it and irrelevant to everyone else. Saying yes to all of them would bloat the core; saying no would push hosts off the platform. The platform needed a third answer.
Chapter 02
What I built
The system first, then the people it serves, then the build log of how it came together.
The system
Client
- React Native app (iOS / Android)
- React web app
- Embeddable checkout bundle
- Chatbot widget
- AI assistants via MCP
Core
- Serverless functions (TypeScript)
- Public REST API + scoped keys
- Plugin sandbox & contract
- Sharded ticket inventory + cart holds
- Organization & profile model
Services & data
- Document database with real-time sync
- Managed auth
- Stripe (tickets, memberships)
- Push / Email / SMS / WhatsApp providers
- Shared packages: types, constants, helpers
New capabilities land in the core first; every client, including the MCP server, consumes the same contract.
A React Native app and a React web app serve hosts and guests; an embeddable checkout and a chat widget serve organizations' own websites; and AI assistants connect through an MCP server. All of them talk to the same core: typed serverless functions behind a public REST API, with a real-time database fanning live updates — RSVPs, ticket counts, chat — to every connected device. Shared packages keep the three surfaces honest: a backend change that would break the app fails at type-check, not in production.
Who uses it
Guest
- Discover events in live 'happening now' and 'upcoming' feeds
- Buy tickets, pick seats, use coupons
- Join as a member of an organization
- Choose notification channels: push, email, SMS, WhatsApp
Host
- Create, publish and close events in a deliberately short flow
- Add invitees, questionnaires, co-hosts, refund policy
- Design venues and assign seats
- Add plugins to an event
Organization
- Run events as a brand with a community hub profile
- Offer memberships with Stripe billing and retry handling
- Manage members and org-level workflows
- Embed checkout and support chat on their own site
Developer / AI assistant
- Call the public REST API with scoped keys
- Prototype in the local API playground
- Author plugins from chat via MCP
- Operate within rate limits and guest-PII redaction
The build log
- 01
Backend first, always. New capabilities land as typed serverless functions and shared types; then the website and app expose them. The three surfaces live in one pnpm monorepo and share packages for types, constants and backend helpers — roughly 60% of the logic is written once and consumed everywhere.
- 02
An Organization is a first-class actor, not a flag on a user. One account can act as a primary profile, an alternate profile or an organization, so hosting as a brand never required a second login — and permissions follow whichever identity is acting.
- 03
Inventory is one model. Paid and free tickets, assigned seats, general admission, admin holds and table bookings all share sharded inventory counters and time-boxed cart holds, so checkout physically cannot oversell — even when a popular event sells out in minutes.
- 04
Plugins run in a sandbox, store their own data, and ship without a core deploy. Hosts add them to an event; the core exposes a stable, versioned contract. The speed-dating matcher, donor wall and promoters wall became plugins instead of core features.
- 05
The public REST API uses scoped keys with rate limits and guest-PII redaction, and the MCP server sits directly on that API — an AI assistant gets exactly the permissions of the key it was given, nothing more.
- 06
Checkout and the support-chat widget ship as separate embeddable bundles that run outside the main app, so organizations can sell tickets and answer questions on their own websites.
Chapter 03
Turning points
The moments that shaped the build, and the roads not taken.
Hosts wanted the same account to run personal events and act as a venue or club — without two logins, and without their personal identity leaking into brand events.
- Challenge
- Model identity so one user can be a person, an alternate profile or an organization, with permissions, privacy and billing that follow the acting identity on every API call.
- Approach
- Introduced the organization as a first-class actor with organization-aware workflows, two-sided contacts and privacy controls — down to which location an identity shares. Every API call carries the acting identity, and ownership checks are cheap string comparisons on structured ids.
- Result
- Organization profiles, org events, memberships and Stripe billing shipped on top of the existing user base with no account migration — and every later feature (API keys, plugins, the AI assistant) inherited the model instead of reinventing it.
Popular events sold out in minutes, and assigned seating made overselling an expensive, publicly visible failure.
- Challenge
- Keep tickets, seats and general admission consistent under concurrent checkouts, where hundreds of carts race for the same seats at once.
- Approach
- Sharded inventory counters with time-boxed cart holds shared by every ticket type, plus admin holds and table bookings on the same model. The venue designer, seat assignment and GA checkout all run on one set of rules.
- Result
- Checkout cannot oversell. Sell-out events became marketing moments instead of support incidents, and the backend held 99.9% uptime through peak event weekends.
Every host had one feature only they needed — a speed-dating matcher, a donor wall, a promoters wall.
- Challenge
- Let hosts extend their events without the core team shipping a release, and without third-party code compromising the app.
- Approach
- A plugin contract and sandbox where plugins render in a controlled environment, store their own data, and reach the platform only through a server-validated proxy. The first three plugins proved the contract; plugins can now also be authored from chat through the MCP server.
- Result
- Hosts add plugins without a deploy; the core codebase stayed focused. The plugin surface turned 'no' conversations into 'there's a plugin for that'.
Organizations wanted ticket sales and attendee support on their own websites, not just inside the app.
- Challenge
- Run checkout and support chat anywhere on the web without embedding the whole product, and without weakening payment or data guarantees.
- Approach
- Checkout and the chat widget ship as separate, self-contained bundles that mount on any host site and talk to the same public API as every other client — same inventory rules, same redaction, same rate limits.
- Result
- Organizations sell tickets from their own domains with the platform's guarantees intact, and thousands in ticket sales flow through embedded checkout with zero bespoke integration work per customer.
Forks in the road
Inventory
Took this road
One inventory model
Not this one
Separate systems for tickets, seats and tables
Sharded counters and cart holds in one place means one set of rules against overselling. A new ticket type is a configuration, not a new subsystem — and sell-out weekends stress one battle-tested path instead of three.
Extensibility
Took this road
Sandboxed plugins
Not this one
Building every host request into the core
Plugins store their own data and ship without a deploy. The core stays small; hosts get the odd feature their event needs. It's a third answer between bloating the product and turning hosts away.
AI access
Took this road
MCP server on the public API
Not this one
A separate AI integration with its own auth
The assistant inherits the key's scopes, rate limits and PII redaction. There is one security model to audit, not two — and anything the API learns, the assistant learns for free.
Codebase
Took this road
pnpm monorepo with shared packages
Not this one
Three repos with duplicated types
Types, constants and backend helpers are written once and consumed by all three surfaces. A breaking change surfaces at type-check time; releases across app, web and backend stay synchronized.
Event creation
Took this road
Relentless flow simplification
Not this one
A powerful but long creation form
Hosts abandon long forms, and an event that never gets created never gets attended. Iterative user testing cut the creation flow's steps roughly in half, and abandonment dropped with it — the single highest-leverage UX work on the product.
Chapter 04
Did it work?
What changed, what shipped, and the notes I kept for next time.
Consumer app vs. platform
| Dimension | Consumer app (2023) | Platform (today) |
|---|---|---|
| Who can host | Individuals only | Individuals, alternate profiles and organizations from one account |
| Tickets | Free RSVPs | Paid and free tickets, coupons, cart holds, assigned seats, tables, admin holds |
| Billing | None | Stripe billing for memberships with failed-payment retry |
| Extending an event | Feature request to the core team | Sandboxed plugins hosts add without a deploy |
| Integrations | None | Public REST API, scoped keys, playground, MCP server |
| Notifications | Push only | Push, email, SMS, WhatsApp with per-user preferences |
The AI layer
The platform ships in the AI era and treats assistants as a first-class client. The same public API that serves partners serves AI agents through MCP — with the same keys, scopes and redaction — so AI capability arrived without a parallel integration to secure.
1
Security model for humans and AI
The MCP server sits on the public REST API. An assistant inherits its key's scopes, rate limits and guest-PII redaction — there is no separate AI backdoor to audit.
Chat
Plugins authored conversationally
A host can describe the feature their event needs and have a plugin scaffolded from chat via MCP, then review and attach it — extending the product without touching the core.
24/7
Support chat that never guesses
The embeddable support widget answers from curated FAQs and the guest's live records, escalating to the team's Slack when confidence is low — attendees get instant answers, the team gets a thread.
0
New endpoints built for AI
Every assistant capability maps to an existing, documented API operation. When the API grows, the assistant grows with it for free.
AI in the build itself · AI accelerated the build as well: CI pipelines were restructured for AI-era commit volume (45% faster), and scaffolding, tests and payload mappings were AI-drafted and human-verified — returning engineering time to inventory correctness and the plugin contract.
Shipped and standing
- The platform expanded from individual hosts to organizations, venues and memberships without a second account model — identity, billing and permissions all ride one design.
- One inventory model covers free, paid, assigned-seat, GA, table and admin-hold tickets with no overselling, through sell-out weekends at 99.9% uptime.
- Hosts extend events with sandboxed plugins; the first three shipped without a core deploy, and new ones can be authored from chat.
- A public REST API with scoped keys, a playground and an MCP server lets partners and AI assistants work with the platform under one audited security model.
- Checkout and support chat run as embeddable bundles on organizations' own websites, processing thousands in ticket sales with no per-customer integration.
- Storybook-driven components, ~60% shared logic and documentation-first practices kept three surfaces shipping in sync with a small team.
Notes to self
Note 01
Put the backend contract first. When three surfaces consume one typed API, the API is the product and the UIs are views of it — and the type-checker becomes your cheapest integration test.
Note 02
The second actor type (organizations) is the real test of a data model. Designing identity as 'who is acting' rather than 'who is logged in' early avoided a rewrite that every later feature would have paid for.
Note 03
AI access should reuse the existing permission model. An MCP server on the public API gave assistants useful power with nothing new to secure — one security review instead of two.
Note 04
A plugin sandbox is cheaper than saying yes to every feature, and more honest than saying no. The contract matters more than the first plugins built on it.