AIFull StackProduct
How I Built Simplay
January 7, 2026|6 min read
16px
Loading
Quick Disclaimer: This blog is inspired by how I actually build projects — not some idealized “clean architecture from day one” fantasy. There was confusion. There were rewrites. But that’s exactly why Simplay exists.
Let’s be honest. Most of us “learn” from YouTube by:
I did this for years. The problem is not lack of content. The problem is passive consumption.
YouTube is incredible, but it’s optimized for watch time, not learning. That’s where the idea of Simplay came from. I wanted videos broken into understandable chunks, clear summaries, and a distraction-free environment.
Most importantly: something that forces me to engage. So instead of complaining about it, I decided to build it.
Simplay is not “AI for the sake of AI”. At its core, it does one thing well: Turns YouTube educational videos into structured, interactive learning material.
The flow is simple:
That’s it. Everything else — dashboards, auth, animations — exists to support that core loop.
Let me be clear: My first version was trash.
I tried to over-engineer the backend, design everything perfectly upfront, and add features I didn’t need yet. Classic beginner mistake. I had no clear data flow, bloated controllers, and frontend components doing too much logic.
At some point, I stopped and asked myself a brutal question:
“If I delete half this code, does the product break?”
The answer was no. That’s when I reset.
Once I calmed down, I rebuilt Simplay by thinking in systems, not features.
This is the heart of Simplay.
This forced me to think about prompt quality, not just API calls. Bad prompt = bad product. No amount of UI polish fixes that.
I kept this intentionally boring.
Why? Because auth is not where you should innovate unless you’re building auth itself. Google OAuth + JWT = reliable, predictable, done.
I avoided Redux on purpose. Instead, I used Context API, clear data boundaries, and Axios for requests.
The rule I followed: If global state doesn’t need to be global, don’t make it global. This kept the frontend sane.
People love overcomplicating stack decisions. Here’s my logic:
Frontend
I wasn’t trying to invent UI paradigms. I was trying to ship.
Backend
And yes, people will say: "Why not Next.js full stack?" Because I wanted clear separation, not magic.
Calling Gemini is easy. Making its output usable is not.
Problems I faced:
The fix wasn’t code. It was iterating prompts, constraining outputs, and treating AI like an unreliable intern, not a god. Once I accepted that, things got better.
I deliberately made the UI calm, minimal, and boring in a good way. No infinite gradients. No unnecessary glassmorphism. Because learning should not feel like a crypto landing page.
Animations exist only when they explain state changes or improve feedback. If it didn’t do one of those, it was removed.
This project didn’t just teach me tech. It taught me that:
Here’s your homework:
Most people never get past step 2.
Simplay isn’t perfect. But it’s real. And that matters more than a polished README or a fancy stack diagram.
If this blog helped you think differently about building products, share it with someone who’s stuck overthinking their next project.
That’s it. 🫡