So, during the writing of my last blog post, I realised that I hadn’t explained what my project is actually about and why I chose to build it, so today I want to dive into that.
Why I Chose to Build a Membership System
When choosing a project for this backend portfolio, I wanted to avoid building something purely academic.
Instead of creating a system that only exists to satisfy a set of technical requirements, I wanted to work on something that:
- solves a real problem
- feels realistic from a business perspective
- can grow over time alongside my skills
That is how the idea of building a membership system was born.
A real-world problem
The original idea came from a conversation with my brother, who owns a fitness center chain.
He asked me if it would be possible to build a better membership system than the one they were currently using, because the existing solution was clunky, limited, and difficult to work with.
That question immediately sparked my interest.
Not because I thought I could instantly build a production-ready system, but because it presented:
- a concrete use case
- real users
- real business needs
- and very real limitations in existing software
Combining school and reality
This project fits perfectly into the goals of the 3rd semester backend portfolio.
It allows me to:
- practice core backend technologies
- work with realistic data models
- introduce complexity gradually
- and reflect on architectural decisions along the way
At the same time, it gives me the freedom to think beyond the classroom.
Even if this system never reaches production, the design decisions, mistakes, and lessons learned will be directly transferable to real-world backend development.
Why a membership system works well as a backend project
A membership system naturally includes many of the challenges that backend systems face in practice:
- users with different roles
- ownership of data (companies vs users)
- time-based data (memberships)
- state transitions (active, cancelled, paused)
- business rules (who is allowed to check in, when, and where)
This makes it an ideal foundation for:
- JPA and relational modeling
- JPQL queries and joins
- service-layer business logic
- authentication and authorization
- validation and error handling
In other words, the problem space itself encourages good backend design.
Building something that can evolve
One of the most important reasons for choosing this project is that it is not finished by design.
The system can grow naturally as new topics are introduced:
- first persistence
- then services
- then APIs
- then security
- then deployment concerns
This mirrors how real software evolves over time.
By sticking to the same domain throughout the semester, I can focus on learning how systems grow, not just how individual technologies work in isolation.
Motivation through ownership
There is also a strong motivational aspect to working on this project.
Knowing that the system is based on a real business scenario:
- makes design decisions feel meaningful
- encourages cleaner structure
- and makes it easier to stay engaged over time
It no longer feels like “just another assignment”.
It feels like something I own, improve, and understand more deeply with each iteration.
Final thoughts
Choosing this project was ultimately about aligning learning goals with real-world relevance.
By building a membership system, I get to:
- practice backend fundamentals
- explore realistic architectural challenges
- and create something that could, one day, be used outside of a school setting
That combination makes this project both technically valuable and personally motivating, which is exactly what I wanted from this portfolio.