
Trading Cards For Change: A Full-Stack MERN Case Study
Published: 6/11/2025
🗃️Github
🥞Tech Stack: MERN, Redux/RTK Query
In the middle of 2024, I hit a technical wall.
I had been working on simple JS/CSS/HTML projects, still learning but missing the kind of challenge that forces real growth. I wanted a cornerstone project. Something that could really define my portfolio and show what I was capable of.
A CRUD or API app might have sufficed, but I needed something deeper. In late August, I committed my evenings to Brad Traversy’s MERN Stack From Scratch course, still not even fully aware of what “full-stack” really meant.
The course filled in major gaps around back-end architecture, data flow, and state management. But reaching the end of the course felt more like a beginning. I didn’t want to just clone the course, I wanted to adapt it into something with a purpose. That opportunity came one night after attending a local nonprofit trading card event.
After speaking with some volunteers I knew, the topic of their web presence came up and they vented about the high platform fees tied to every event reservation. That was my lightbulb moment: nonprofits deserve a viable, open-source alternative to conventional event platforms.
Major Challenges & How I Conquered Them
1. Scope creep is a project killer. There were several moments where I felt in over my head. I thought I could simply "tailor" the course project, but that was naive. The most brutal example was adding recurring and nonrecurring events through the admin panel, something that demanded multiple rewrites I hadn’t planned for. Better planning would have saved me from a lot of stress.
2. I have lots of newfound respect for state management, because Redux was quite a mind-bender at first. Managing state across slices, async actions, and understanding mutations (thanks to Immer) pushed me further than I expected. But it made me much more deliberate in how I structure state in apps now.
3. Real UX means real people using what you make, and making things look nice isn’t the same as making them usable. From mobile dropdowns to layout bugs, polishing TC4C for real users taught me that “responsive design” can only be an iterative process full of unforeseen challenges.
Crashing Near the End, and Rising From the Ashes
One of the last customizations I made to the system was the ability for admins to create both recurring and nonrecurring events, something that required syncing RRule logic between the UI, the backend, and the booking calendar. Somewhere between prompting Gemini and ChatGPT back and forth, the complexity spiraled to a point where the code was no longer maintainable or something I could fully own. The logic became a black box. My understanding was unraveling, and even worse, my confidence was fading too. I could even feel my foundational skills getting dull.
I made the hard call to revert to an earlier commit, and started over.
It was while I was picking through the ashes of all the code I had just left behind that I discovered the "Socratic tutor" approach to prompting, getting AI to teach by asking instead of answering. With enough persistence (and some deep dives into the RRule documentation), I rebuilt the booking system from scratch. Being able to understand it fully then allowed me to translate that into a working event edit page that facilitates even custom recurring events.
What's Next for TC4C?
Although the needs of the company I was working with have changed, I remain committed to the philosophy of this project. TC4C has been a constantly-evolving sandbox during my full-stack evolution, and I want it to mature into a proper open-source project that serves real people doing real work.
Here's what's next:
- More animations, UX polish
- Accessibility improvements
- Documentation & setup templates
- Testing coverage with Vitest
- A final, concise release for small charities and event organizers to clone and get to work immediately
Closing Thoughts
I didn't just learn more about JavaScript and React. This project tested my ability to think, and to think ahead. Every big, scary problem had to be broken into smaller parts that could always be toppled with enough intuition and research. Each time I overcame a problem, I came out even stronger. Not just as a developer, but as a problem solver. This project made me slow down, refocus, and become more intentional about how I learn and how I build.
Thanks for reading. If you’ve worked on a similar project, or just want to talk code, find me on LinkedIn. I’d love to connect!
- Terrell