Building the Platform for the 5th National Data Science Summit: A Tech Lead’s Diary

We recently wrapped up the 5th National Data Science Summit, and I built the website and the entire operations platform behind it from scratch.

The platform handled everything: participant registration, project submission, check-in management, certificate generation, judging, and a full admin portal, all under one roof. While everyone else was enjoying the event, I was busy debugging whatever was breaking on line 98. Here’s how I handled one of the more chaotic moments, and what I learned along the way.

Timeline

The event was held on July 12th. I started building on July 1st. The initial goal was to make the platform robust enough that we wouldn’t need a second app for anything registration, submissions, judging, all under the same hood.

Tech Stack

Next.js — Used the App Router for the frontend, with built-in API routes handling the backend, all in a single monorepo.

Database & Auth — MongoDB for the database. Since time was tight, I used Kinde for authentication and RBAC (Role-Based Access Control).

Storage & Mail — Google Cloud APIs for mailing and object storage. We collected a google workspace emails through university .

Analytics — Redis (via Upstash) as a temporary analytics store.

Deployment — Vercel.

Registration, Reinvented

Normally, event registration goes: Google Form → Excel sheet → printed copy handed to every organizer. Replacing that was the first task.

The new flow: a team leader creates an account, forms a team, and adds participant emails. Payment was handled manually via bKash/Nagad, we didn’t have all resources to integrate a real payment gateway and permision, so we verified payments by hand.

Simple enough in theory, except it wasn’t that simple. This was a national event with participants joining from clubs across different universities. We partnered with over 15 clubs, offering a 10% discount to members of partner clubs, and we needed to track exactly who paid through which club. So we built a coupon system, which ended up handling 80+ coupons across those 15+ partner clubs.

Five Segments, Five Sets of Requirements

The event ran five segments: Data Hackathon, Project Showcase, Promptcraft, Research Poster Presentation, and a Hands-on Workshop.

Project Showcase and Research Poster Presentation required participants to submit project documentation, a video, and an abstract through the portal all uploaded seamlessly, with 50+ submissions between the two segments.

Data Hackathon and Promptcraft were live, real-time competitions, both running on a timer with problem statements released on the spot. Promptcraft was a themed, live video-making challenge using AI video generation tools. For communication, we built a broadcast mailing tool into the admin panel, with generic and template-based options, so organizers could message all participants, or just specific segments or individuals, without the emails looking like an afterthought.

The Data Hackathon: From Simple Scoring to Full Notebook Review

The Data Hackathon followed a Kaggle-style format: participants received a problem statement, a training set, and a test set, then submitted predictions.

The original plan was simple extract the F1 score by comparing the submitted prediction CSV against the ground-truth CSV. But that approach was easy to game, so we required a full notebook submission instead, letting us inspect the actual code and flag anything suspicious.

We tested the system with a mock contest first about 35 contestants, up to five submission attempts each and it went well. But we still worried about manipulated prediction files, and we didn’t have time to manually review every submission. So, right before the event, we made a late but important call: rebuild the system to actually execute each submitted model a few times and capture accuracy, runtime, and other metrics directly, so judging would be fair and verifiable.

That decision landed very close to the event, and building it alone wasn’t realistic. This is where my friend Shihab stepped in and built the execution backend himself.

Participant-Facing Features

Dynamic Seat Planner — Participants could see exactly which seat and room they’d been assigned, visualized in the portal.

QR Check-in — Every participant got a QR code. Volunteers used a dedicated portal to scan it, pull up the registration record, confirm verification status, and check off perks like check-in, lunch, and snacks.

Certificate Generation — Once checked in, each participant’s portal generated a personalized certificate of participation instantly, ready to download and share.

Judge Portal

To replace pen-and-paper judging, we built a judge portal where judges could see their assigned projects or contestants, review rubric criteria, and enter marks directly. Straightforward in theory but the day of the event had other plans, which I’ll get into below.

Event Day: Chaos

The event opened to a full day of rain and flooding, forcing us to delay the start by an hour. We used that hour to walk every volunteer through the portal and the day’s flow.

The night before, I didn’t slept a bit I was still rebuilding the hackathon submission system on a new backend. That’s when it hit me: we needed real analytics, or we’d be debugging blind if anything failed live. I got the Redis analytics pipeline running to track hot routes and traffic spikes, so we could pinpoint issues instead of guessing. Event morning, I had three monitors going: one on live analytics, one on Vercel logs, one for active debugging.

The check-in code mix-up. Participants started arriving, but the check-in access code I’d distributed was wrong a simple mistake on my end that confused a lot of people. I had to resend the correct code quickly. A volunteer also flagged an accessibility issue with the check-in flow, which I patched live in about 10 minutes.

Judge onboarding, live. Several senior faculty members were judging, and despite clear instructions, some hadn’t created their Kinde accounts. To cut the friction, I built a one-time magic link on the spot: it silently created an account behind the scenes and, on click, dropped the session cookie straight into the judge’s browser no manual login needed. A few judges still preferred pen and paper, so we added a way for admin to enter those scores into the portal on their behalf.

Promptcraft and the Vercel rate limit. Right as Promptcraft submissions opened, I got an email from Vercel we’d blown through the plan’s limits: 1 million edge requests and 4 hours of fluid compute, mid-contest. We had to optimize the request path on the fly to keep serving submissions. We also hit Google Drive/Google Cloud API rate limits during video uploads, which caused failed uploads for a number of participants most got through after two or three retries, but it was a rough experience that came down to GCP’s own limits rather than anything in our control.

Data Hackathon: the deep end. This was the most technically demanding piece every submission triggered execution of a model file, notebook, and requirements file, on a backend that had never been tested at scale before showtime. We hit validation issues in real time: some participants submitted incomplete sets (say, a model file but no notebook or prediction CSV), and we had to decide, live, how to score partial submissions fairly. Shihab and our faculty advisor, Izaz Ahmed Sir, took this on directly and got the hackathon judging pipeline stable and working through the day.

Coordination. As tech lead, every technical fire was mine to put out while also coordinating volunteers invigilating the Data Hackathon and Promptcraft (to prevent cheating), liaising with the venue’s IT team on internet and power issues, and pushing fixes to the registration, submission, and hackathon systems in parallel.

By the Numbers

By day’s end, the platform’s live dashboard told the story: 328 unique participants across 267 teams, competing in 5 signature events. Check-in reached 187 teams (70%), with 355 seats assigned, 28 BYOD participants, and a crew of 16 judges and 8 volunteers keeping things running, backed by 15 issued coupons.

Team turnout by event: Promptcraft (85 teams), Hands-On Workshop (70), Data Hackathon (60), Project Showcase (31), and Research Poster Presentation (21).

Submissions totaled 118: 40 for Promptcraft, 31 for the Data Hackathon, 30 for Project Showcase, and 17 for Research Poster Presentation.

Traffic-wise, the platform logged 9,587 all-time pageviews, with 196 concurrent visitors at peak, most of it concentrated on the main dashboard (1,748 views), the homepage (1,704 views), and the final-round submission portal (635 views).

Lessons Learned

Load-test before showtime, not during it. The hackathon backend and the Vercel rate-limit hit both came from pushing untested systems straight into live traffic. A single dry run at expected scale would have surfaced both issues days earlier, when there was still room to fix them calmly.

Build analytics in from day one, not the night before. I only wired up the Redis analytics pipeline the night before the event, out of instinct that we’d need it. We did — immediately. If something breaks live, you need visibility into what broke before you can fix it; don’t wait until you’re already worried.

Assume auth friction, and have a fallback ready. Even with clear instructions, some judges didn’t create accounts in time. Building a “break-glass” option (the magic-link flow) ahead of the event, rather than improvising it live, would have saved a stressful hour.

Manual verification and paper fallbacks aren’t a failure they’re a safety net. Letting volunteers submit judge scores on paper, and manually verifying bKash/Nagad payments, felt like compromises at the time. In hindsight, they were exactly what kept the event running when the “proper” digital flow hit friction.

Third-party limits are part of your architecture. Vercel’s edge request cap and Google’s Drive/API rate limits weren’t bugs in our code, but they were still our problem to design around. Next time, I’d map out every vendor’s limits against expected peak load before the event, not discover them mid-contest.

A single tech lead is a single point of failure. Having Shihab step in on the hackathon backend saved the event, but it happened out of necessity, not planning.

Closing Thoughts

Given the resource and communication constraints we were working under, I’m proud of how much of this held together and how much we managed to fix live, in the moment, without the whole thing falling over. A big shout-out to Claude Code, which helped me debug and ship fixes on the fly throughout the day.