Midnight Madness: The Meltdown
I built Midnight Madness as an end-to-end ticketing experience for a Halloween party, covering event discovery, ticket selection, payment, and post-payment communication. I also built an admin side that tracked payments, attendee status, and entry verification, so the team could run the night with less guesswork.
Live link not available as event has already ended.
Tech Stack
Tailwind • TypeScript • Flask • MySQL • Clerk • Paystack • Hubtel (SMS)
TypeScript
Tailwind CSS
Python (Flask)
MySQL
Clerk
Paystack
Hubtel (SMS)
Context
Project Overview
The product was built to handle high-intent traffic close to the event date, reduce failed purchases, and give organizers a reliable view of payments and attendance.
The landing experience was structured around quick answers: what the event was, when it was happening, where it was located, and how to get a ticket in under a minute. The ticket flow was intentionally short, with clear tier states like sold out and coming soon.
After payment, the platform sent SMS notifications via Hubtel, so buyers received a fast, mobile-first confirmation even if they never checked email. Authentication and admin access were protected with Clerk to keep operational tooling separate from the public flow.
The admin side was built as a true operations panel, not a basic table: it tracked who paid, when they paid, the ticket tier, and attendance status, so the team could validate entry and reconcile payments without spreadsheets.
Built to optimize for
- Purchase claritySimple ticket tiers
- Trust & verificationPayment confirmation
- Operational controlAdmin attendance view
- Perceived performanceLoading states
Primary users
Party-goers
Fast ticket purchase flow
Internal users
Event staff
Payments + attendance tracking
UI
Screenshots
These were the key screens I designed to move users from interest to paid tickets, and to give organizers a clean operational view.
Event landing page (date, location, and poster preview) with a clear ticket CTA.
Replace image paths with your actual screenshots in /public.
Ticket selection flow with tier states (sold out, active, coming soon) and a real-time summary.
Replace image paths with your actual screenshots in /public.
Checkout step integrating payments with a friction-minimized confirmation experience.
Replace image paths with your actual screenshots in /public.
Admin dashboard for payment verification, attendance tracking, and operational visibility.
Replace image paths with your actual screenshots in /public.
Decisions
Key Product Decisions
I built the flow like an event funnel: fast context, clear ticket choice, reliable payment, immediate confirmation, and a back-office that stayed accurate during the rush.
Scroll-driven reveal with Framer Motion
I designed ticket tiers with clear states
Decision 1I treated tiers as a predictable system: early bird could be sold out, regular could be active, and late could be coming soon. This reduced confusion and prevented users from attempting unavailable options.
I integrated Paystack for payments
Decision 2I implemented a payment flow that focused on conversion reliability and clean post-payment verification, so organizers could trust what the dashboard was showing.
I used Hubtel SMS for confirmations
Decision 3I sent SMS confirmations after successful payment so buyers got immediate feedback on mobile. It also reduced support messages like “Did my payment go through?”
I protected admin access with Clerk
Decision 4I implemented role-protected access for the admin side so internal data stayed private and only authorized staff could view payments and update attendance status.
I built the admin side as an operations panel
Decision 5I stored payment records with timestamps and linked them to attendance. Staff could verify entry quickly and keep a reliable record of who had attended.
I implemented loading states for perceived performance
Decision 6I used structured loading states to keep layouts stable, reduce visual jumping, and make the flow feel fast during peak traffic windows.
Build
Architecture & Data Flow
The platform separated the public purchase journey from internal operations, while keeping one consistent source of truth in the database.
The frontend was built with TypeScript and Tailwind for fast UI iteration and consistent styling. The backend API was built in Flask and connected to MySQL for durable storage of ticket purchases, attendee records, and admin actions.
Clerk handled authentication and gated access to admin routes. Paystack handled payment initiation and confirmation, and Hubtel delivered SMS confirmations after successful transactions. The admin dashboard pulled from the same payment records, so staff always saw the latest verified state.
Data path
- 1User landed on the event page and selected a ticket tier
- 2Frontend initiated payment via Paystack
- 3Flask validated and stored the transaction in MySQL
- 4Hubtel sent SMS confirmation to the buyer
- 5Admin dashboard displayed payment and attendance state (Clerk-protected)
- 6Staff updated attendance when attendees arrived
Admin capabilities
- • View all paid tickets with timestamps and tier
- • Search/filter attendees by name, phone, or ticket type
- • Mark attendance status at entry
- • Track totals for paid vs attended
Outcome & Impact
The final result was a production-ready event ticketing platform that handled the full buyer journey and gave organizers a clean admin view for reconciling payments and managing attendance. The combination of Paystack verification, Hubtel SMS confirmations, and a Clerk-protected admin panel reduced operational friction and kept event-day decisions data-driven.
Want the full breakdown (DB schema, endpoints, and admin workflows)? I can add a short “Implementation Notes” section beneath this case study.
/public/projects/midnight-madness/ and keep the names aligned with the screenshots array above.