The challenge
Small hosts usually piece their set-up together from separate products: a profile page here, a ticket seller there, a payment provider and yet another service for promotion. Each one does its own job. The cost shows up in the gaps between them. Guests move across pages that look unrelated, the host’s branding changes at every step, and the host ends up copying the same details from one place to the next.
Evntt set out to close those gaps. Any creator should be able to have a professional, largely automated presence plus the everyday tools of hosting, and guests should have a single place to discover events and book tickets.
That made it a two-sided product from the first commit, which shaped the main technical risk. Hosts and guests act on the same events, tickets and bookings, yet they want very different things. Hosts need editing tools, dashboards and a dependable route for their income. Guests need to spot something worth attending and book it quickly. If the core records were designed around one side and bolted onto the other, every later feature would have to be built twice.
The brief came down to four needs:
- A host profile that hosts can brand and adjust themselves, with no designer involved
- Ticketing and booking on the same pages where guests find the event
- Promotion tools that are ready as soon as an event goes live
- Dashboards, light analytics, merchandise and galleries inside the host’s own account
Our approach
Our first decision was the stack, and we kept it mainstream on purpose. The front end is React with TypeScript and Tailwind CSS, the back end is Node.js, data sits in PostgreSQL, payments go through Stripe and the platform runs on AWS. For an early-stage product, a bigger danger than old-fashioned tools is a codebase that only its first authors can work on. Familiar technology keeps hiring, handover and outside help simple, and leaves the room for invention in the product itself.
Second, the profile editor shows every change as it happens. Hosts adjust their branding and watch their page update alongside, instead of saving and opening a separate preview to check. We spent time here because the profile is the first thing a guest sees, and a host who can’t get it looking right won’t share it. The page in the editor and the page guests visit are the same page, so publishing brings no surprises.
Third, a relational database at the core. An Evntt account is a chain of linked records: hosts own events, events offer tickets and guests hold bookings against those tickets. PostgreSQL is built for exactly that shape of data and keeps the connections between records clear and consistent. We cared most about this where money is involved.
Fourth, card payments go to a specialist. Billing runs through Stripe, so card handling stays outside Evntt’s own systems. For a young platform that takes a large share of the security and compliance burden off the table, and it lets the build effort go into hosts and guests instead of payment plumbing.
Fifth, promotion lives inside the product. The moment an event is published it has its own QR code and share links, so a host can start promoting straight away without reaching for another tool. Event dashboards, lightweight analytics, merchandise and galleries sit in the same account for the same reason: every extra app a host needs is one more place the experience can come apart.
Finally, AWS hosting suits the way demand for events behaves. Traffic is often quiet and then arrives in a rush when a well-followed host shares a new date. Cloud capacity can grow for those moments instead of being paid for at peak size all year.
Architecture & stack
- Front end
- React, TypeScript, Tailwind CSS
- Back end & data
- Node.js, PostgreSQL
- Payments
- Stripe
- Hosting
- AWS
The outcome
A small host on Evntt now has what once meant hiring a designer and juggling several services: their own branded page, plus ticketing, billing, promotion and reporting, all under one login. Guests can browse events and book them without leaving the platform.
For the business, a single codebase and a single data model serving both sides means a new feature reaches hosts and guests at the same moment, with no connectors between outside services to maintain. The stack is mainstream enough to be extended by an in-house team or passed to another supplier.
What we’d advise a founder building a similar two-sided product: design the shared data model before either side’s screens, leave card payments to a provider that specialises in them, build sharing into the product from day one, and pick technology another team could take over without a rebuild.
- Profile, ticketing, payments and promotion in a single product
- Live-preview branding that hosts manage on their own
- A QR code and share links for every published event
- Card handling kept with Stripe, away from Evntt’s own systems
Last updated