Building Varnage: What a “Student Project” Looks Like When You Treat It Like a Real Product

Most student projects are built to pass a course.

Varnage wasn’t.

When I started working on Varnage, I already knew the problem space painfully well — not from market research slides or fictional user personas, but from actually running an esports team myself. I had felt the friction, the inefficiencies, and the quiet frustration that builds up when tools technically work, yet constantly get in the way.

The Background: Running an Esports Team Like a Professional One

Before Varnage existed, I founded and owned an amateur esports team that was deliberately structured like a professional organization. We didn’t do casual tryouts. Instead, we ran a structured application process, organized full test‑out tournament weekends, and had candidates play against each other in controlled competitive settings. To reduce bias, we even invited established professional players from the scene to help evaluate performance, communication, and decision‑making.

There is a deeper write‑up of this process on the LCA Esports blog, but what mattered most for Varnage was the perspective it gave me. Talent evaluation is hard — but once you start operating seriously, organization becomes the real bottleneck.

The Frustration That Sparked the Project

Running a team like this quickly exposed how poor most existing esports tools really were. They were usable, but that was about it. Interfaces were cluttered, workflows unintuitive, and design often felt like an afterthought. Mobile support was technically present, yet clearly not a priority. Nothing felt cohesive or intentionally designed for people who actually live inside these tools every day.

I constantly found myself compensating. Scrims were coordinated in one place, announcements in another, calendars somewhere else entirely, and performance data had to be pieced together manually. Over time it became obvious that the problem wasn’t missing features — it was missing product thinking.

At some point the question became unavoidable: if I already knew exactly what a team like mine needed, why not build the tool I actually wanted to use?

Turning a University Project into a Real Product Attempt

When a university web engineering project came up, I made a conscious decision to treat it differently. I didn’t want to build a fictional app for fictional users. Varnage became an attempt to solve a real problem for a real audience, with a real commercialization path in mind.

I had something most student projects don’t: an actual esports team ready to use the product. I talked to my players regularly, asked what annoyed them, what they ignored, and what genuinely helped them improve. That feedback loop shaped Varnage far more than any requirements document ever could.

The vision was a central hub for Valorant teams — a place where scrims, announcements, team context, and performance data lived together, without forcing users to jump between tools.

Wrestling with the Riot API

One of the defining experiences of the project was working with the Riot ecosystem. For weeks, a large part of my time went into getting the Riot API and Riot Sign‑On working at all.

This is not an API that everyone can casually use. You have to apply, clearly explain your use case, and wait for approval. Once approved, you don’t get a polished developer portal or hand‑holding documentation. You get a simple webpage listing endpoints and a Word document describing the OpenID integration.

Making this work required experimentation, trial and error, and a lot of reading between the lines. Rate limits had to be respected, authentication flows had to be correct, and real match data had to be fetched and displayed without breaking the user experience. It was frustrating at times — and incredibly rewarding once everything finally clicked.

Learning Next.js by Doing Real Server‑Side Work

At the time, I was still relatively new to Next.js. Varnage became the project where it truly stopped being “just a React framework” for me.

Instead of relying purely on client‑side data fetching, I leaned heavily into server‑side rendering and preloading. Pages were designed to arrive with meaningful data already in place — announcements, scrim information, team context — so users weren’t staring at loading states. This wasn’t just a performance decision; it was a UX decision, especially for users on unstable connections.

Looking back, this part of the project shaped how I think about modern web applications much more than any tutorial ever could.

Design, Branding, and the LCA Ecosystem

The Honest Part

Varnage never reached its full vision.

It shipped as a working, deployed proof‑of‑concept, but reality intervened. Time constraints, shifting priorities, and the natural limits of an academic setting meant that not everything made it into the final version.

And yet, years later, it remains one of my favorite projects.

Not because it was perfect — but because it was real.

Why This Project Still Matters

Varnage represents something I still deeply believe in: building software as if it might actually be used, even when nobody forces you to do so.

It reinforced lessons that still guide my work today. Good UX isn’t optional. Product thinking belongs in engineering. Domain knowledge beats speculation every time. And a “student project” doesn’t have to mean a toy project.

I still think Varnage is worth finishing someday. The problem hasn’t gone away — and neither has the motivation.