Every Project Starts With a Problem
As most inventions or ideas begin, mine also started with a problem.
For me, it was in the gym.
I often found myself missing workouts here and there for various reasons — some completely beyond my control. That part is normal. Life happens.
What I struggled with was figuring out how to recover from it.
Most people would simply say:
"If you missed Back Day, just do it tomorrow."
And yes, that works.
But I've always liked having specific workouts on specific days. 'Monday will always be my Chest Day' 😤
That's when an idea hit me.
What if I built a Gym Scheduler that could intelligently reorganize the rest of the week whenever I missed a workout?
The long-term vision is to eventually integrate AI so it can generate personalized workout adjustments based on a user's goals, schedule, and missed sessions.
And since this problem affects me personally, it felt like the perfect project to build.
Before Writing Code, We Planned
One of the most valuable lessons my coding mentor taught me was this:
"Always plan before you build."
A surprising number of development problems can be avoided simply by thinking things through before touching the keyboard.
This became even more important when working with powerful tools like Claude Code.
My initial prompt was something along the lines of:
"I want to build a Gym Scheduler app. Let's brainstorm some ideas first. Ask me lots of questions and create a planning file where we can organize everything."
And that's exactly what happened.
What started as a simple idea quickly became a massive planning document covering:
- Architecture
- Authentication
- Database structure
- API routes
- Features
- Deployment strategy
- Build phases
Before a single line of code was written, the entire project had a roadmap.
Honestly, I did not expect the planning file to become this huge 😅
Claude Became My Project Manager 😅
Since I'm still a student developer with a lot left to learn, I didn't want Claude to simply write code for me.
I wanted it to teach me as well.
At several points, I even asked Claude to explain what it was doing and why it was doing it.
One of my goals for this project was to better understand:
- Object-Oriented Programming (OOP)
- SOLID Principles
- Application architecture
Claude suggested the following stack:
| Technology | Role |
|---|---|
| React | Frontend framework |
| Tailwind CSS | Styling |
| MongoDB Atlas | Database |
But instead of blindly accepting the suggestion, I asked it to justify every choice.
Why React? Why MongoDB? Why not something else?
This ended up being one of the most educational parts of the project — it helped me understand not just what to use, but when to use it.
Building It Phase by Phase
Once the planning was complete, we finally started building.
One thing I specifically asked Claude to do was avoid generating the entire application in one go.
Instead, I wanted it built phase by phase.
This turned out to be one of the best decisions of the entire project.
Benefits for me:
- Easier to learn
- Easier to understand
- Easier to debug
Benefits for Claude:
- Smaller tasks
- Fewer mistakes
- Better code reviews
At one point I even stopped everything just to ask:
"What exactly is a model?"
And instead of throwing code at me, Claude explained the concept and how it fit into the project.
The learning part is always important, no matter how powerful AI becomes.
Watching the App Come Alive ✨
At first, all I could see was a blank page with the floating React-Vite logo.
Not exactly exciting 😭
Then slowly, feature by feature, the app started taking shape:
- A login system appeared
- Workout schedules started displaying correctly
- Exercises could be added and deleted
- Pages started connecting together
And suddenly something that had only existed inside a planning document was becoming a real application.
I genuinely couldn't believe how much faster the development process felt compared to some of my earlier projects.
For example, in a previous project, building a simple login system involved:
- Watching a 1-hour YouTube tutorial
- Reading Firebase documentation
- Asking ChatGPT for help
- Getting even more errors 😭
This time felt completely different.
Of course... not everything went perfectly.
The "It Works On My Machine" Moment 😭
After finally getting everything working locally, I deployed the application.
And then immediately got hit with this:
Everything worked perfectly on my computer. Production had other plans.
After spending hours investigating the issue, I discovered the problem was hiding inside Google Cloud Console.
My callback URI was only configured for localhost and was missing the deployed Render URL.
A tiny configuration mistake. Several hours of debugging. Classic developer experience 😭
But eventually, after updating the configuration and redeploying, everything finally started working.
The First Version Wasn't Pretty... But It Worked 💪
The first working version looked nothing like the version I use today.
There were no fancy tools, no advanced features, no polished UX, no AI scheduling.
Just the basics:
- ✅ Add exercises
- ✅ Delete exercises
- ✅ Rename workout splits
- ✅ Store schedules
And honestly? That was enough.
Because it worked.
For the first time, I had a functional application solving a real problem that I personally faced.
And that felt amazing.
What's Next?
The first version was functional — but it was also very rough.
In Part 2, I'll talk about how I transformed it from a simple scheduler into something much more polished by adding:
- Multiple programs
- Exercise reordering
- Current-day highlighting
- BMI Calculator
- Calorie Calculator
- Better UI/UX
- And some fun gym-specific touches 😎
Unfortunately... waiting for me was the most frustrating bug of the entire project so far 😭🙏
See y'all in the next one 🚀
Top comments (0)