Lessons from building QwickAttend.

It started with a broken register

The attendance register at my school was a mess. Papers everywhere, unclear records, teachers spending ten minutes at the start of every class doing something that should take thirty seconds. I was annoyed enough to think I could fix it. That annoyance turned into QwickAttend.

What I expected to build: a simple QR scanning system with a dashboard. What I actually built: something much messier, more complex, and more interesting than that. Here's what the process actually taught me.

Your first architecture will be wrong

I made confident decisions early on about how the data should be structured. Attendance records tied to sessions, sessions tied to classes, classes tied to teachers. Clean, logical, obvious. Two months in, I realized I needed to support multiple teachers per class, attendance windows per session, and exception handling for late arrivals — none of which fit my original schema cleanly.

I rewrote the core data model twice. Each time was painful. Each time produced something significantly better. The lesson wasn't to plan better upfront — it was to build in a way that makes rewrites survivable. Keep things modular. Don't couple everything together in the first sprint. Leave room for the inevitable rethink.

The feature nobody asked for becomes the one everyone uses

I added ID card generation late, almost as an afterthought. It wasn't in any original spec. I built it in a weekend because it seemed useful. It became one of the most-used features of the entire system.

The attendance tracking was the core product. The ID cards were the thing people talked about. Real users find value in places you don't predict. That's not a reason to build everything — it's a reason to stay curious about what adjacent problems your system could solve once the core is working.

Mobile is not a feature, it's the product

I built the desktop dashboard first because it was easier. Then I built the mobile views as an afterthought. Then I rebuilt the mobile views from scratch because they were unusable.

Teachers aren't sitting at computers when they take attendance. They're standing at the front of a classroom with a phone. Every interaction needed to work with one hand, in bad lighting, under time pressure. None of that was true on desktop. The two products had completely different constraints and I treated them as the same product for too long.

If your product lives on mobile — and most products live on mobile — design for mobile first. Not as a responsive breakpoint. As the primary experience.

"I built the desktop version in weeks. I rebuilt the mobile version three times. The mobile version is what people actually use."

Real users break things in thirty seconds that you missed in months

I tested QwickAttend extensively before showing it to anyone. I thought I'd found most of the issues. The first real user took thirty seconds to hit a bug I'd never encountered. Then another. Then another.

This isn't a failure of testing. It's a fundamental truth about software: you cannot simulate real users. They have different mental models, different workflows, different devices, different network conditions. They do things you'd never think to do. They skip steps you assumed were obvious. They need things you assumed were unnecessary.

Ship to real users as early as you can tolerate. Their confusion is not your failure — it's your most valuable dataset.

Supabase saved me months

Using Supabase for the backend was one of the better technical decisions I made. Auth, database, real-time subscriptions, storage — handled. I focused on the actual product logic instead of infrastructure. For a solo developer building something real, the right tools aren't cheating. They're how you survive.

Know what you're trying to learn and what you're willing to abstract away. I wanted to learn about building a multi-user system with real-time data. I didn't need to learn how to run a database server. Supabase let me stay focused on the former.

The thing that surprised me most

The hardest part of building QwickAttend wasn't the code. It was staying motivated through the parts that weren't working yet. The weeks where the system was half-functional and every session ended with more bugs than you started with. The moments where the whole architecture felt wrong and starting over seemed easier than continuing.

Shipping something real requires tolerating a sustained period of the product being worse than you can imagine it being. That tolerance is a skill. You build it the same way you build everything else — by doing it, getting through it, and remembering that the broken middle is not where the product ends up.

QwickAttend isn't done. Products like this are never done. But it works, it's used, and I understand more about building real systems than I ever would have from courses or tutorials alone.

Build the thing. That's still the best advice.