A modern online invitation and RSVP platform - pay-per-event, no guest accounts, everything in one place.
// 01
Invitify was built around a simple problem: organising events is still more fragmented than it should be. For many small events, people rely on a mix of WhatsApp messages, spreadsheets, calendar invites, payment links, manual reminders, and copied guest lists. That works for very small gatherings, but it quickly becomes messy once the organiser needs to track RSVPs, dietary requirements, plus-ones, reminders, guest changes, and event updates in one place.
The goal of Invitify was to create a lightweight, polished alternative to overly complex event management platforms. It is aimed at people hosting birthdays, baby showers, weddings, BBQs, networking events, fundraisers, sports club events, and small business gatherings. The product focuses on making it easy to create a beautiful invite, share a public RSVP link, collect guest responses, and manage the guest list without forcing attendees to create accounts.
From a product perspective, the interesting challenge was balancing simplicity with enough flexibility to support different event types. A wedding invite needs different fields from a casual BBQ or business networking event, but the organiser experience should still feel consistent. Invitify is therefore designed around reusable templates, structured RSVP settings, and a pay-per-event model rather than a heavy monthly subscription.
// 02
Invitify was designed as a full-stack SaaS-style application with a clear split between the frontend experience, backend API, persistence layer, billing, asynchronous jobs, and automated testing.
The frontend was built with Next.js and TypeScript because the product needs a strong visual experience, fast public invite pages, SEO-friendly event template pages, and a maintainable React architecture. TypeScript made the event creation flow easier to model safely, especially around event types, RSVP settings, guest responses, publication status, and pricing tiers.
The backend was built with Python, Django, and Django REST Framework. Django provided a mature foundation for modelling events, guests, RSVPs, templates, users, payments, and permissions, while DRF made it straightforward to expose a clean API to the Next.js frontend. PostgreSQL was chosen because the application is highly relational: events have guests, guests have RSVP states, published events have public slugs, and billing state needs to remain consistent.
Stripe was used to support the pay-per-event pricing model, allowing organisers to publish paid events through a checkout flow. Celery and Redis were included for asynchronous work such as reminder workflows, email/SMS sending, webhook processing, and any future scheduled guest communications. pytest was used to build confidence around API behaviour, event lifecycle transitions, RSVP submission, validation rules, and billing-related flows.
// 03
The most interesting part of Invitify was designing the product model so it could support many event types without becoming messy. A birthday, wedding, baby shower, company BBQ, fundraiser, and sports club awards night all share common concepts, but each can require slightly different data. I had to think carefully about where to use structured fields, where to allow optional configuration, and how to keep the API flexible without turning the event model into a dumping ground.
Another tricky area was the event lifecycle. Draft events, published events, archived events, public RSVP pages, guest management, and payment status all interact with each other. For example, an organiser should be able to prepare an event privately, publish it once payment succeeds, share a stable public URL, collect RSVPs, and later archive it without breaking historical data. Getting those transitions right required careful backend validation and a clear separation between internal organiser routes and public guest-facing endpoints.
I'm particularly proud of the balance between product polish and backend structure. Invitify is not just a UI experiment; it has real SaaS concerns behind it: pricing tiers, Stripe payments, public/private API boundaries, asynchronous reminders, reusable templates, and test coverage with pytest. It also helped me deepen my Python and Django experience while building something close to a real commercial product.