04 / Event
HackFinity3.0
I co-organised the hackathon, then built the app that judged it.
HackFinity 3.0 was RIT's 24-hour hackathon on 18 and 19 September 2026. I was one of its organisers, and I built the Android app that every participant, judge and coordinator used on the day, along with the event website.
- Role
- Co-organiser; built the judging app and event site
- When
- 18 and 19 September 2026
- Scale
- 31 teams, 114 participants
- App
- Expo, React Native, Convex
Case file
01
The event
24 hours, 31 teams, one scoring system
Organising meant registrations, problem statements, check-in and judging all had to work on the day, for every team, with no second chance.
- 50 problem statements, 25 software and 25 hardware, on a searchable board with PDF downloads.
- A ₹30,000 prize pool: ₹15,000, ₹10,000 and ₹5,000.
02
The judging app
One app, five kinds of user
One email can hold several roles, and each role sees only its own tabs. Screens update live from Convex subscriptions and raise local alerts when something changes.
- Participants see their team, a help desk, updates, and results once they're published.
- Evaluators score teams on a 10-criterion rubric and see the leaderboard.
- Coordinators scan badges and mark attendance, but never see marks.
- Organisers import teams, set up rounds, manage logins and send announcements. Only the master organiser can change a signed score sheet.
- backend functions
- 117backend functions
- tables
- 15tables
- commits, all mine
- 15commits, all mine
03
Scoring
Marks nobody can quietly change
Ten criteria, each out of ten: innovation, implementation, impact, presentation, feasibility, technical depth, user experience, problem fit, scalability and teamwork. Organisers can re-weight any of them.
- A round's mark is the mean of its submitted sheets, drafts never count, and ties go to the later round, then the earlier registration.
- Rounds move from draft to open to locked, and results publish once, only after every round is locked and every team is scored.
- Judges can share a login, so every sheet must be signed. Internal judges enter an employee ID that is checked against the faculty roster.
- Master authority comes from the deployment's environment, not from a database field anyone could edit.
04
On the day
Scan, score, done
Check-in and judging ran from the same phones.
- Every badge carries a QR code and a Code 128 barcode from an encoder I wrote.
- The scanner reads QR, Code 128 and Code 39, ignores repeat scans for 2.2 seconds, and has a torch and a typed-code fallback.
- Coordinators mark each member present, late, excused or absent, with nothing filled in for them.
- A cold-start race made queries run before sign-in finished. They now wait for auth, and a recovery boundary retries instead of showing an error page.
05
The website
An event site that feels like launch night
The public site carries the tracks, prizes, coordinators and the problem board.
- A pinned GSAP hero zooms the title as you scroll, with Lenis smooth scrolling driving ScrollTrigger.
- A canvas starfield stretches into hyperspace streaks the faster you scroll.
- Problem statements live in Convex with a publish flag, and a static copy keeps the site building without it.
Built with
- Expo
- React Native
- Convex
- Better Auth
- Reanimated
- expo-camera
- Next.js 16
- GSAP
- Lenis
- Tailwind CSS 4
- TypeScript
next case file
RIT REACH
The institute's own course platform. I built its exams and the invigilation behind them.
Read it