SYDR — Soyongdori Club Website

Hello everyone. Before we get into the slides, we'd like to start with a short pre-recorded demo video so you can get a feel for the actual product — what it looks like, how it flows, and what it can do — before we explain how it was built. Please take a look.

Alright, now that you've seen the product in action, let's walk through the slides and explain the decisions behind it.

Our project is called SYDR — short for Soyongdori. Soyongdori is the central band club here at Chungbuk National University, and SYDR is the web platform we built for it.

Before this project, the club ran almost entirely on manual processes. Announcements went out over KakaoTalk, event schedules lived in personal calendar apps, and documents were scattered across Google Drive with no consistent structure. There was no single place to find anything.

Membership management was just as fragmented. Joining the club meant filling out a form somewhere and waiting for someone to manually approve it. No one could easily see who had what role, and when leadership changed every semester, there was no structured handover — the next president just got a spreadsheet and hoped for the best.

Access permissions were also unclear — in practice anyone who had the Google Drive link could see everything, which is a real security risk. And club accounting meant someone manually photographing receipts and typing amounts into a spreadsheet by hand. Our goal was to replace all of that with one systematic, always-accessible web platform: proper permission controls, durable archiving, and a clear workflow for every process the club relies on.

Before we get into the individual features, here's the overall structure of the site. There are about thirteen screens, organized by permission tier. A visitor starts as a guest, signs up to become a temporary member, submits a membership application, gets approved by an admin, and finally becomes a full member — and what each screen shows and allows follows that progression. You can think of this map as the blueprint that ties together all the features I'm about to walk through.

A quick rundown of what we used. The whole project is written in TypeScript — a typed superset of JavaScript — on both the frontend and the backend. On the frontend: React, Tailwind CSS, and FullCalendar.js. On the backend: Node.js with Express, as a stateless REST API. The database is MySQL with Prisma as the ORM. And for infrastructure, we deploy with Docker Compose on Oracle Cloud, with Cloudflare handling the tunnel and the CDN.

Our first key feature is the permission system. We implemented a Role-Based Access Control model using JWT — JSON Web Tokens — for stateless authentication. When a user logs in, the server issues an access token and a refresh token. The access token carries the user's job title — their position — and the server derives the permission level from that on each request. It never needs to look up a session in the database, which keeps the API fast and horizontally scalable.

For granularity, we defined permission levels from zero to eight, derived from the club's job-title hierarchy. A brand-new applicant is level zero, a regular member is level one, the club president is level seven, and the system super-admin sits at the very top, at level eight. A couple of titles even share a level — our treasurer and planning lead are both level five. On the backend, we built a custom Express middleware using a helper called requireLevel, which wraps any route you want to protect. If the token's level doesn't meet the threshold, the request is rejected right at the middleware layer — before any business logic runs.

Concretely, permissions control: who can write or only read on the bulletin board, who can access the admin dashboard, whether a user can create and edit calendar events or just view them, and who can see personal member information. This directly solved the access-control problem the club had before — where visibility into club data was basically all-or-nothing.

The second feature is the membership application workflow. We designed it as a four-step pipeline. In step one, a prospective member signs up on the site: a user record is created, their status is set to "pending," and their basic info is saved to the MEMBERS table.

In step two, they fill out an application form — their instrument part and a short motivation. That data gets inserted into a separate JOIN_APPLICATIONS table, linked to the user record via a foreign key.

Step three: the admin opens the dashboard and sees a list of pending applications. There's an approve or reject button for each one. One click is all it takes — no spreadsheets, no KakaoTalk messages back and forth.

And step four is where everything resolves atomically. When an application is approved, it's processed within a single transaction: the user's status changes to "active," and permissions are automatically granted based on their job title — all in one atomic step. Because it's transactional, there's no state where a user is approved but still has no permissions, or vice versa. Data integrity is guaranteed.

Third feature: the user interface itself. One of the most visible parts of the site is the schedule management system, built on FullCalendar.js. It's a custom integration of the library, set up so that personal, member, and official calendars can be configured separately, all with real-time rendering. Members can create events, while editing or deleting is limited to the event's author or a vice-leader and above.

Responsive design was a core priority. The same codebase runs on a wide desktop monitor and on a 375-pixel-wide phone screen without any separate mobile site. We used Tailwind's responsive utilities throughout so every layout adapts seamlessly — which matters because club members check the schedule on their phones far more than on a desktop.

The fourth feature was probably the most exciting one to build. On the club's accounting board, you can upload receipt images. The system runs automatic character recognition and parsing, automatically extracting the dates, the number of items, and the amounts. This streamlines how the club manages its ledgers — no more manual transcription.

Under the hood, we integrated the Google Gemini 3.1 Flash Lite API. We chose it because it's a lightweight LLM with fast response times, which makes the AI feature cost-effective for a student project with real usage. The key engineering work was getting sophisticated, well-structured output through systematic prompting — a clean format with a date, item, quantity, and price for every line, plus a total. Once we had it dialed in, the results were surprisingly accurate even on low-quality receipt photos.

For collaboration, we used a structured Git branching strategy. Each new feature lived on its own feature branch. We integrated on a shared dev branch where we could run tests and catch cross-feature issues. When things were stable, we merged into main via pull requests. And releases got their own tagged release branches so we always had a clean production-ready snapshot.

Every merge went through a pull request review. Team members read each other's code and left comments before anything landed on main. One person primarily owned merge responsibility and handled final bug checks before promoting to main or a release branch. This kept our main branch stable throughout the semester — we had a working, deployable version at all times.

Now I want to talk about the real challenges we hit — the things that didn't work the first time and what we did to fix them. These were some of the most valuable learning experiences of the project.

So where are we now? We have a fully deployed, production-grade TypeScript web platform that replaces every manual process the club was relying on. The deployment is live on Oracle Cloud behind Cloudflare. Real club members are using it for testing right now, and we're collecting feedback for the next iteration.

Looking ahead, we plan to continue improving the platform based on real usage — refining the admin experience, expanding the AI receipt analysis, and potentially adding push notifications for event reminders. The foundation is solid, and the architecture is set up to support these extensions without a rewrite.

Being honest about what's left, one of the first things on our list is how much of the site is still hardcoded. Right now the home page's hero images, the part photos on the introduction page, and even highlights like our next stage and rehearsal times are baked into the code at build time — there is literally a "TODO" comment in our home page reminding us to wire these up to the API. The next step is to move that content into the database and give club officers a small admin panel, so changing a poster or an announcement doesn't require a developer and a redeploy.

On the infrastructure side, uploaded files like profile pictures are currently stored as local file paths on the server, and high-resolution uploads can degrade — both already flagged as TODOs in our schema and code. We plan to move file storage to object storage such as MinIO or Cloudflare R2, fix the high-resolution handling, and replace the last few magic numbers — like the club's founding year and the default cohort — with values driven by configuration and the database. We've also already laid the groundwork in our schema for archiving the boards year by year, which ties directly back to our original goal: durable, organized record-keeping that survives every leadership handover.

Now let's switch over to the live site. I'll walk through a few key flows so you can see everything working in real-time.

First, the sign-up and membership approval flow. I'll create a new account — you can see the form validates in real-time. After sign-up, the account is in "pending" status. Now I'll fill out the membership application form. Let's switch to the admin dashboard — here's the application sitting in the queue. I'll approve it, assign a job title, and you'll see the status flip to "active" instantly, with permissions granted automatically.

Next, the calendar. I'll create a new event — notice that the interface is fully responsive. Let me resize the browser window down to phone width, or better yet, here's the same page on my phone. The calendar adjusts automatically — no horizontal scroll, everything fits. This is the concrete outcome of the responsive work we described earlier.

Finally, the AI receipt analysis. I'll navigate to the accounting board and upload a receipt image. Watch what happens — within a couple of seconds the system parses the receipt and populates the date, items, and total amount automatically. No typing required. This is the Gemini API at work behind the scenes.

That's everything for our presentation. To summarize: we built SYDR — a full-stack TypeScript web platform for a real university band club — covering RBAC authentication, automated membership workflows, a responsive interactive calendar, and AI-assisted accounting. The site is live, it's responsive enough to use on the phone you're holding right now, and it's already in the hands of real users.

The source code is public at github.com/openWEBsw/project-soyongdori. We'd love for you to take a look, and if you want to check the responsive design claim for yourself, you can open the live site on your phone right now. Thank you very much for listening — we're happy to take any questions.