Event management system project
registration, tickets and QR check-in

Organisers publish events with sessions and ticket types, people register, each ticket carries a QR code checked at the door, and attendees leave feedback. Generate a working version, then make it yours.

Generate this project

What the project does

Generated from the prompt below, so yours can differ: read it before you present it.

Events and sessions

Venue, date, description and a schedule of sessions with speakers, published on a public page.

Ticket types and seat limits

Free, student or regular tickets, each with a price and a limit. The last seat cannot be sold twice.

Registration

Attendees register on the event page and get a ticket with a QR code and their own link to it.

QR check-in

At the door, the organiser's phone scans the ticket. A ticket checks in once; the count of who has arrived updates live.

Feedback

After the event, attendees rate it and leave a comment; organisers see the average per event.

Reports

Registrations per ticket type, attendance against registrations, and payments marked as received.

Who uses it

Admin: Approves organisers and sees every event.
Organiser: Creates and runs their own events: tickets, check-in, payments, feedback.
Attendee: Registers, keeps their tickets, checks in, gives feedback: only their own registrations.

ER diagram

Eight entities. A registration is one person's ticket of one type for one event; check-in and feedback hang off it. The seat limit lives on the ticket type.

organiser

id	uuid	PK
name	text
email	text	UK
organisation	text

venue

id	uuid	PK
name	text
address	text
capacity	int

event

id	uuid	PK
organiser_id	uuid	FK
venue_id	uuid	FK
title	text
event_date	date
status	text

session

id	uuid	PK
event_id	uuid	FK
title	text
speaker	text
starts_at	timestamp

ticket_type

id	uuid	PK
event_id	uuid	FK
name	text
price	numeric
seat_limit	int

attendee

id	uuid	PK
name	text
email	text	UK
phone	text

registration

id	uuid	PK
ticket_type_id	uuid	FK
attendee_id	uuid	FK
ticket_code	text	UK
paid	bool
checked_in_at	timestamp

feedback

id	uuid	PK
registration_id	uuid	FK
rating	int
comment	text

Relationships

organiser runs event (one to many)
venue hosts event (one to many)
event has session (one to many)
event offers ticket_type (one to many)
ticket_type is booked as registration (one to many)
attendee holds registration (one to many)
registration receives feedback (one to one)

Mermaid source

Paste it into mermaid.live, draw.io (Arrange, Insert, Advanced, Mermaid) or any Markdown editor that draws Mermaid to get the diagram for your report.

erDiagram
  ORGANISER ||--o{ EVENT : "runs"
  VENUE ||--o{ EVENT : "hosts"
  EVENT ||--o{ SESSION : "has"
  EVENT ||--o{ TICKET_TYPE : "offers"
  TICKET_TYPE ||--o{ REGISTRATION : "is booked as"
  ATTENDEE ||--o{ REGISTRATION : "holds"
  REGISTRATION ||--|| FEEDBACK : "receives"
  ORGANISER {
    uuid id PK
    text name
    text email UK
    text organisation
  }
  VENUE {
    uuid id PK
    text name
    text address
    int capacity
  }
  EVENT {
    uuid id PK
    uuid organiser_id FK
    uuid venue_id FK
    text title
    date event_date
    text status
  }
  SESSION {
    uuid id PK
    uuid event_id FK
    text title
    text speaker
    timestamp starts_at
  }
  TICKET_TYPE {
    uuid id PK
    uuid event_id FK
    text name
    numeric price
    int seat_limit
  }
  ATTENDEE {
    uuid id PK
    text name
    text email UK
    text phone
  }
  REGISTRATION {
    uuid id PK
    uuid ticket_type_id FK
    uuid attendee_id FK
    text ticket_code UK
    bool paid
    timestamp checked_in_at
  }
  FEEDBACK {
    uuid id PK
    uuid registration_id FK
    int rating
    text comment
  }

Generate yours and get the code

This builds on Refinar's invitations starting point, which already has events, guests with a private link, RSVP and QR check-in at the gate. Ticket types, seat limits, sessions and feedback come from the prompt.

The button opens Refinar with the project described in the first message, ready to edit. About a minute later there is a running app with sign-in, the pages above and a PostgreSQL database, in a live preview you can click through and change by asking.

It is real code: Next.js and React in TypeScript, PostgreSQL with the Drizzle ORM, and Better Auth for sign-in. When you press Go live, the GitHub repository moves to your own GitHub account and the database to your own Neon account, so you can read it, run it and present it. Building uses credits and going live needs a Refinar plan; the details are on the pricing page.

If your syllabus asks for PHP and MySQL, Java or Python, ask your guide before you start: the generated code will not be in those languages. The ER diagram and the checklist on this page work for any stack.

The prompt it starts with

An event management system for a final-year project, in English, for college fests and workshops: organisers create events with venue, date, description and sessions with speakers; ticket types with a price and a seat limit that cannot be oversold; a public event page where people register and get a ticket with a QR code; check-in at the door by scanning the QR code, with a live count; feedback with a rating after the event; reports of registrations and attendance per event. Payment is marked by the organiser, no online payment. Roles: admin, organiser, who manages only their own events, and attendee.

Generate this project

Report and viva checklist

Report checklist

Abstract: the problem, who uses the system and what it does, in one paragraph.
Existing system and its problems, then the proposed system.
Objectives and scope, including what is out of scope.
Requirements: functional and non-functional, per role.
Technology used and why: Next.js, TypeScript, PostgreSQL, Drizzle ORM.
ER diagram and table design, normalised to third normal form.
DFD level 0 and level 1, and a use case diagram.
Module description with a screenshot of each screen.
Testing: test cases with input, expected result and actual result.
Conclusion, limitations and future scope.
References, and a statement of the tools you used, AI included.

Make the report about this project

Explain how overselling is prevented when two people book the last seat together.
Show what the QR code contains and why it is a random code rather than the registration id.
Draw the registration flow: registered, paid, checked in, gave feedback.
Test cases: scanning a ticket twice, registering after the limit, an organiser opening another organiser's event.

Viva questions to prepare

Why is feedback linked to a registration and not directly to an attendee?
How do you count seats left for a ticket type? Write the query.
What should happen to registrations if an event is cancelled?
How would you add online payment without breaking the seat limit?
What is a primary key and a foreign key? Point to one of each in your tables.
Which normal form are your tables in, and what would break if they were not?
How does sign-in work, and how are passwords stored?
How does the app stop one user from seeing another user's data?
Why PostgreSQL, and not MySQL or MongoDB?
What did you change or add yourself, and why?

Build it, understand it, then submit it

Many universities allow tools, AI included, as long as you say so and can explain every part of what you submit. Read your university's rules and ask your guide before you start, and name Refinar in the tools section of your report.

Treat the generated app as a starting point, not a submission. Read every table and every page, change something yourself, add one feature that is your own, and write the test cases by hand. If you cannot say why a table has a foreign key, an examiner will find out in a minute.

Submitting work you did not do and do not understand as your own is academic misconduct, whoever or whatever wrote it. These pages are here to help you build a project you can defend.

Take it further

Online payment through a provider's test mode, with seats held for 10 minutes during checkout.
Email confirmations with the ticket attached.
Certificates of participation generated as PDF for checked-in attendees.
A waiting list that offers a freed seat to the next person.

Questions

What modules does an event management system project need?

Event and session management, ticket types, registration, check-in, feedback and reports, with logins for admin, organisers and attendees.

Does QR check-in really work on a phone?

The invitations starting point checks tickets in from a link the phone's camera opens, and scans in the browser where the browser supports it. Test it on the phones you will use on the day.

Can it be for weddings instead of college fests?

Yes. Change the prompt: guests and families instead of tickets, RSVP with the number of companions, and a gate check-in. That is close to what the starting point does already.

Is it free?

Building uses credits from a Refinar plan, and getting the code into your own GitHub account goes through Go live, which needs a plan. The details are on the pricing page.

Event management system projectregistration, tickets and QR check-in