Ticketing Was the Easy Part. Owning the Audience Wasn’t.
DrisTix – a multi-tenant event platform with a built-in attendee CRM, split payouts, and a door scanner that keeps working when the Wi-Fi doesn’t.
Overview
DrisTix is an event platform for organizers who’d got tired of running their business across five tools that don’t speak to each other. Ticketing in one place, email in another, a spreadsheet of last year’s attendees somewhere in a Drive folder, payouts landing whenever the platform felt like releasing them, and a volunteer at the door with a printed list and a highlighter.
The brief was to pull all of that into one product sell tickets, take the money, pay the organizer, build the event site, email the audience, scan at the door. What made it interesting wasn’t the ticketing. It was everything that had to hold together underneath it. As a CRM development company, we built the platform around the thing organizers actually own: the list of people who showed up last time.
Challenge
Once we got into it, here’s what the product genuinely had to solve:
The audience list belonged to nobody
Ticketing tools sell tickets and stop there. Organizers were exporting CSVs into Mailchimp and losing the thread between who bought what and who to talk to next. That relationship data had to live in the platform, not get shipped out of it.
Venue wifi is bad and the queue doesn’t wait
Check-in happens in basements, fields and converted warehouses, with four hundred people arriving in twenty minutes. A scanner that needs a live API call per ticket fails exactly when it matters most.
The money has to split, and Stripe retries
Organizer gets paid, platform takes its fee, both off one card transaction. The hard part isn’t the split — it’s what happens when an organizer hasn’t finished onboarding, or when a webhook gets delivered twice.
Three codebases, one API contract
Web and mobile shipping on separate schedules against a shared backend. Keeping them properly independent, with no shared code, took discipline rather than good intentions.
Our Approach
We built it in modules instead of marching toward one big launch date. Ticketing first, then payments, then payouts, then subscriptions, then the email engine, then the website builder. Each piece shipped when it was ready. That’s why the database has 65 migrations behind it rather than one enormous schema someone wrote in week two and regretted by month four.
The backend runs a strict layered flow—routes, controllers, services, repositories—and we actually enforced it instead of leaving it as a diagram in the onboarding doc. It looks bureaucratic on paper. In practice, it’s why you can hire python developer and have them find where something lives without asking anyone, even across 38 route modules. The web and mobile work ran as separate teams, making it easier to hire dedicated developers to work against the same contract.
Solution Delivered
The attendee CRM is the part organizers stay for. Segment an audience by who attended, who came before, or who’s holding a ticket to something upcoming. Build a campaign in five steps, personalise it with merge tags so it references someone’s actual ticket, and set automations to fire on triggers rather than on somebody remembering. Abandoned checkouts get chased automatically. Email goes out from the organizer’s own domain through SES, which is the difference between the inbox and the promotions tab — a small detail that quietly decides whether any of it works.
Check-in assumes the network will fail, because it will. Scans hit the server when there’s a connection and fall back to an on-device SQLite database when there isn’t, queueing up and syncing back in a batch on reconnect. Honestly, this is the piece we’re most pleased with, and the one no organizer will ever notice — which is rather the point.
On payments, every Stripe and SES webhook gets checked against a ledger before anything happens, so a retried delivery can’t double-charge anyone. Split payouts run through Connect, and if an organizer hasn’t finished onboarding the sale still completes and settles to the platform rather than failing at checkout. We drew on our fintech software development work for the payment side and our events and ticketing experience for the rest.
Key Features
The pieces that carry the product, for organizers and for the people at the door.
Built-in₹ attendee CRM
Segment by attended, past or upcoming events, and market to that list without exporting it anywhere.
Offline ticket check-in
On-device validation and a queued sync, so the door keeps moving when the connection drops.
Email automation
Triggered sends, merge tags, open and click tracking, and abandoned-cart recovery.
Stripe Connect payouts
Split payments to organizers, with a safe fallback when an account isn’t onboarded yet.
Drag-and-drop site builder
Organizers publish a branded event site with custom domains, version history and rollback.
Three portals, one platform
Public, Organizer and Admin, each with the permissions and oversight that role needs.
Results and Outcomes
Engineering figures from the build as of August 2026 development is ongoing. Swap in measured business numbers before publishing.
65:
Migrations shipped module by module, rather than one big-bang schema.
148
Automated backend tests, weighted toward permissions, exports and payments.
38
API route modules under one versioned contract, serving web and mobile.
3
Independent codebases, each free to ship on its own schedule.
Technology Stack
Chosen for a platform that has to keep growing without seizing up.
FastAPI + Python
Backend API across 38 route modules, layered and predictable.
PostgreSQL + SQLAlchemy
Relational core with 65 Alembic migrations of history behind it.
React + TypeScript
Three portals in one SPA, built on Vite, Tailwind and shadcn/ui.
React Native
Check-in companion app with camera scanning and offline storage.
Stripe + Connect
Payments, split payouts, subscriptions, all webhook-verified.
AWS SES + SNS
Email delivery on organizer-owned domains with per-recipient logging.
Conclusion
Organizers don’t lose customers because their checkout was ugly. They lose them because the relationship lives in someone else’s tool, and the next event starts from a cold list. DrisTix keeps that data where it belongs and builds the ticketing around it, which is a custom CRM development problem as much as an event one. If you’re building a platform where customer data is the actual product, hire CRM developers who’ll get the schema right before it’s expensive to change and build the platform module by module.
Let’s build success Together
