Project type: Web App / Community registration system | Location: Box Hill & Vermont, Melbourne | Completed: 2025
Some projects feel interesting from the start.
This client wasn't looking for a corporate website or an e-commerce store. He's a basketball enthusiast—booking courts in Box Hill and Vermont every week, recruiting on social media, organising games for everyone. He does it purely because he loves it. But that love was slowly being worn down by the grind of admin work.
When he came to us, he said something that stuck:
"I want to play basketball, not be an admin."
Table of Contents
- What Was the Real Problem?
- How We Planned It
- What We Hit During Development
- What This Project Taught Us
- In Closing
What Was the Real Problem?
Before we wrote a line of code, we spent a lot of time understanding his day-to-day.
Problem 1: Not enough people
A full-court game needs at least 10 people. But every week on game day, he was anxious: how many would show up? Would they be stuck with seven people on the court again? When numbers drop, game quality drops—and everyone's time is wasted. More importantly, the joy of playing disappears.
Problem 2: Payments were a disaster
After every session, he had to manually confirm in the WeChat group who had paid and who hadn't. Payment methods were all over the place—bank transfers, cash, screenshots. Then he'd open Excel and log each one manually. Twenty people per session meant nearly an hour of this.
Once a week, over fifty times a year.
Problem 3: No-shows
People who sign up but don't show—a problem in any community activity. In basketball it's especially critical, because numbers directly determine whether you can play a full game. Repeat offenders had no consequences, and there was no mechanism to enforce them.
Problem 4: No real community feeling
He didn't want a "show up, play, leave, never see each other again" vibe. He wanted to build a real basketball community—people who know each other, feel a sense of belonging, and stick around long term. But WeChat groups alone are too limited for that.
How We Planned It
After understanding these four core problems, we made an important decision with the client: don't try to build everything at once.
That sounds obvious, but in practice it's hard—because clients always want more, and developers can easily get pulled into "we might as well do it" logic.
We split the project into two milestones.
Milestone 1: Solve the Most Painful Problems First
Goal: Get him out of repetitive work.
The first phase focused on three things:
1. Registration system Players can sign up online for each session. The system shows real-time attendance—how many people, how many spots left. No more manual counting in WeChat. When the threshold is hit, the system notifies—no more anxiety about whether enough people will show.
2. Settlement Session fees are handled directly on the platform. Who paid, who didn't, full history—all visible at a glance. Excel was retired.
3. Community homepage A homepage that feels like a community—photos and notes from each session. Not just a functional tool, but a place people want to come back to. New members get a sense of the vibe; regulars find shared memories.
After Milestone 1 launched, the client saved over two hours every week. But more importantly, he said playing felt easier—because he knew before the session whether they'd have enough people, instead of stressing on game day.
Milestone 2: Turn the Tool Into a Platform
Once the core logic was validated, we started thinking bigger: could this system be more than a registration tool—could it be a real community platform?
That idea opened the door to new possibilities.
Stripe top-up system We integrated Stripe so players can pre-load their account balance. When signing up, they pay from the balance—no need to pay separately each time. This looked like a payment change, but it changed the whole experience—players started thinking of the platform as "my account," not just a sign-up link.
Experience points system One of our favourite features. Every session you attend, you earn experience points. Points affect your rank and future sign-up priority—which directly addressed the no-show problem. No-shows lose points; active participation gains them. No manual enforcement needed; the system keeps it fair.
More importantly, experience points added a gamification layer. Players started caring about their rank and their place in the community. That's exactly the community feeling we wanted.
Extensible category architecture Designing the system as a platform, not just a tool, had another benefit: it could later extend to football, badminton, kids' training, or even commercial sponsors and SEO. The first version's architecture was built with this in mind, so future expansion wouldn't require a rebuild.
What We Hit During Development
Any honest case study has to include the rough parts.
Scope creep
The client is full of ideas—that's a strength, but it's also a project management challenge. Midway through development, new feature ideas kept coming. Sometimes they were genuinely valuable; sometimes one player requested something and the client wanted it built right away.
We made a clear decision: every new request had to answer one question—is this feature for most users, or for one person?
That question filtered out a lot of "sounds reasonable" features that didn't belong in this version. We explained this logic to the client; he understood and agreed. It cost some communication time, but saved far more development time and cost.
"Can you just add this too?"
The classic line in every development project. Every "just" hides real development time. Our approach: log it, evaluate it, put it in the next milestone or quote it separately—instead of saying "sure, no problem" and then quietly absorbing it.
Transparency beats compliance.
On-time delivery
In the end, we delivered both milestones on schedule. No delays, no surprise invoices.
The client's words: "Finally I can just focus on playing."
What This Project Taught Us
One: Real needs hide behind complaints. The client initially said "I need a registration system." The real need was: I want to do this thing I love better, but I don't want to be crushed by admin work. Understanding that layer is what makes a product actually useful.
Two: Iteration isn't compromise—it's wisdom. If we'd tried to build experience points, Stripe, and multi-category from day one, the project would likely have slipped, and the client would likely have lost patience. Launch first, validate, then extend—that order protects everyone.
Three: Saying no is part of the developer's job. Filtering unnecessary requests isn't rejecting the client—it's protecting the project. A good development partner isn't just an executor; they're also a consultant.
Four: Small problems aren't small. A basketball enthusiast spending an hour a week on Excel bookkeeping—that doesn't sound like a big deal. But multiply by fifty-two weeks, multiply by his passion for this thing, and it's big enough to take seriously.
In Closing
This project wasn't the biggest in scope or the most technically complex. But it's one we're proud of—because it solved real problems, delivered on time, and the client genuinely felt the difference in how he uses it.
That's what we aim for at RiaLab with every new project: not just delivering a website or a system, but delivering something that makes the client's life or work better.
If you have something that's "hard to say exactly what you want, but you know the current way is painful," we'd be glad to talk →
RiaLab is a Melbourne web development studio, focused on fixed-price websites, e-commerce, and web apps for small businesses and founders.
Related Articles: