Festivo — Event Management & Ticketing Platform

Overview

Festivo.io started from a simple question:

Why does running an event still require so many disconnected tools?

For many small and mid-sized organizers, especially university clubs and independent event teams, running an event often means combining Google Forms, spreadsheets, payment screenshots, Facebook posts, manual attendee lists, and separate check-in processes.

I wanted to build a simpler system where an organizer could manage the full event lifecycle from one platform.

That became Festivo.

Why I Built It

The original idea came from observing how organizers manage events manually.

Creating the event itself was rarely the hard part.

The operational mess started afterwards:

• collecting registrations
• confirming payments
• keeping attendee records updated
• managing different ticket types
• sending tickets
• validating people at the gate
• preventing duplicate entry
• tracking sales
• exporting attendee data
• understanding event performance

A small event could survive with spreadsheets.

But as attendance grows, the same workflow becomes difficult to control.

I wanted Festivo to remove that operational overhead.

The goal was not to build another event landing-page generator.

The goal was to build an operating system for event organizers.

The Problem I Wanted to Solve

The core problem was fragmentation.

An organizer might use:

Facebook → Google Form → bKash/payment verification → Google Sheets → Messenger/Email → Manual check-in

Every additional tool creates another place where data can become outdated or incorrect.

For organizers, this creates problems such as:

• duplicate records
• slow payment verification
• poor visibility into ticket sales
• complicated attendee management
• difficult entry validation
• no central source of truth
• unnecessary manual communication

For attendees, the experience is also inconsistent.

They should not need to wonder whether their registration was confirmed or search through messages to find proof of purchase.

Festivo was designed to make the journey straightforward:

Discover → Register → Pay → Receive Ticket → Attend → Scan

What I Built

I developed Festivo around the main workflows an organizer actually needs.

Event Creation

Organizers can create and configure an event with:

• event information
• date and time
• venue
• organizer details
• ticket configuration
• event imagery
• pricing
• registration settings

The focus was to keep event creation simple enough that a small organization could publish without needing technical knowledge.

Ticket Management

Different events need different pricing structures.

Festivo therefore supports multiple ticket types so organizers can manage categories such as:

• Early Bird
• Regular
• VIP
• Student
• Free Registration
• Limited Allocation

Each ticket can have its own price, quantity and availability.

This gives organizers more control without forcing them to maintain separate spreadsheets.

QR-Based Entry

One of the most important features was event check-in.

Each valid ticket can be represented through a QR-based ticket that can be verified during entry.

This helps reduce:

• manual attendee searching
• duplicate entry
• fake screenshots
• long check-in queues

The goal was to make the gate experience fast:

Scan → Validate → Admit

Organizer Dashboard

I wanted organizers to understand what was happening without manually calculating everything.

The dashboard brings important information together, including:

• ticket sales
• attendee numbers
• ticket category performance
• event performance
• registration activity

Instead of searching through individual transactions or spreadsheet rows, organizers get a centralized view of the event.

Attendee Management

The attendee table became another core part of the product.

Organizers can work with attendee information from one place instead of maintaining external sheets.

The platform was designed to support workflows such as:

• viewing attendees
• searching registrations
• filtering records
• checking ticket information
• importing attendees through CSV
• exporting data when required

This was important because I did not want Festivo to force organizers to abandon their existing data.

It needed to fit into their workflow first.

Organizer Profiles

Events are not isolated products.

People often attend events because they trust the organization behind them.

So I introduced organizer profiles where an organization can maintain its own identity and have multiple events associated with it.

This creates a stronger foundation for recurring organizers rather than treating every event as an independent page.

Coupons and Promotions

Organizers often need promotional pricing for:

• communities
• partners
• early registrations
• campaign codes
• special attendee groups

Coupon support was included so these campaigns could be managed inside the same platform instead of being handled manually.

The Product Challenge

Building the interface was not the hardest part.

The harder part was deciding how much to build.

Event platforms can become enormous very quickly.

It is easy to start adding:

• seating plans
• advanced CRM
• marketing automation
• sponsorship systems
• community features
• complex finance modules
• merchandise
• full venue management

That would have killed the MVP.

So I kept returning to one question:

What does an organizer need to successfully publish an event, sell or distribute tickets, manage attendees and run entry?

Anything outside that loop was secondary.

That decision helped keep the first version focused.

Designing the Organizer Experience

One of my main priorities was reducing the amount of thinking required from organizers.

The basic workflow became:

Create Event → Configure Tickets → Publish → Receive Registrations → Manage Attendees → Scan Tickets → Review Performance

Every major feature was designed around this flow.

This sounds simple, but getting there required removing unnecessary steps and avoiding features that looked impressive but added little operational value.

Technical Implementation

Festivo was also an opportunity for me to build a complete product rather than work only on one part of a software system.

The platform was built using technologies including:

Frontend

Next.js · React · Tailwind CSS · shadcn/ui · Redux · Recharts

Backend

Node.js · Express · Prisma

Infrastructure

Vercel · AWS Lightsail · Neon

Authentication

Clerk

The architecture was designed so the platform could start small while still giving me room to introduce more complex organizer, payment and event-management functionality later.

Building for Real Users

A major difference between Festivo and a portfolio side project is that I did not want to stop after building the interface.

I started putting it in front of actual organizers and early users.

The product entered early access with a small group of users, and organizers began testing the platform in real event-management scenarios.

That changed how I thought about the product.

Once someone actually uses your software, problems that seemed small during development suddenly matter.

Questions become more practical:

• Can an organizer understand this without me explaining it?
• Is creating a ticket fast enough?
• What happens when attendee information is wrong?
• Can staff find a registration quickly at the entrance?
• What happens if the internet is slow?
• Is important information visible at the right moment?

Real usage forced me to think beyond feature completion and focus more on operational reliability and usability.

What I Learned From Early Users

Early users helped expose the difference between what I assumed organizers wanted and what they actually needed.

Organizers care less about sophisticated dashboards than developers sometimes expect.

They care about things like:

• Is registration working?
• Did the attendee pay?
• How many tickets are left?
• Can I find someone quickly?
• Will the QR scanner work at the gate?
• Can my team access the right information?
• Can I export my attendee list if needed?

That feedback influenced how I prioritized the product.

It pushed Festivo toward being a practical operational tool rather than a feature-heavy event SaaS.

The Business Model

I also designed Festivo as a business rather than only a technical project.

Instead of relying entirely on large monthly subscriptions, the model can align revenue with successful events through ticket transaction fees.

The idea is simple:

If organizers grow, Festivo grows with them.

This reduces the initial barrier for smaller organizers while creating a path toward sustainable revenue as ticket volumes increase.

Starting With University Events

One of the initial target markets was university clubs and student organizations.

This was deliberate.

University events provide a strong testing environment because they frequently organize:

• competitions
• seminars
• concerts
• workshops
• club events
• conferences
• cultural programs

Yet many still operate through forms and spreadsheets.

Starting with this market gives Festivo a focused user segment where the pain is visible and organizers are relatively accessible.

The longer-term goal is to learn from this market before expanding the platform toward a broader audience.

What I Actually Solved

Festivo does not try to solve every problem in the event industry.

It solves a much narrower operational problem:

Before

Event information in one place.

Registration somewhere else.

Payments handled manually.

Attendees stored in spreadsheets.

Entry managed through lists or screenshots.

Reporting calculated manually.

With Festivo

Event → Tickets → Registration → Attendees → QR Entry → Analytics

inside one connected workflow.

That is the core value of the product.

My Role

Festivo is one of the projects where I have worked across almost the entire product lifecycle.

My work included:

Product Strategy · Problem Discovery · UX Planning · UI Design Direction · Frontend Engineering · Backend Planning · System Architecture · Pricing Strategy · Feature Prioritization · Deployment · User Feedback · Product Iteration

Building it forced me to switch continuously between the mindset of a:

developer, product manager, designer and founder.

The Result

Festivo moved beyond being an idea or UI concept into a working product that real users could interact with.

That is probably the most important result for me.

Instead of spending months trying to perfect every feature, I focused on shipping a usable platform, exposing it to users and learning from how they actually behaved.

The product continues to evolve based on those lessons.

What This Project Taught Me

Festivo taught me something I did not fully understand while working only as a software engineer:

Shipping software is not the same as building a product.

Software can be technically correct and still solve the wrong problem.

Building Festivo required me to think about:

• who the user actually is
• what they are trying to accomplish
• what features should not be built
• how the product makes money
• how users discover it
• what happens during real operations
• where users become confused
• which problems are important enough to solve

That experience has influenced how I approach almost every project now.

Closing Statement

I built Festivo because event organizers should spend their time running great events—not connecting forms, spreadsheets, payment records and attendee lists together manually.