How I Built Simplay
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.
The problem I was obsessed with#
Let’s be honest. Most of us “learn” from YouTube by:
- Opening a video
- Watching the first 5 minutes
- Skipping randomly
- Zoning out
- Closing the tab and feeling productive without actually learning anything.
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.
What Simplay actually is#
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:
- Take a YouTube video
- Extract the transcript
- Feed it to an LLM (Gemini)
- Generate summaries, insights, and structure
- Present it in a focused UI
That’s it. Everything else — dashboards, auth, animations — exists to support that core loop.
Early mistakes (yes, plural)#
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.
Breaking the project into systems#
Once I calmed down, I rebuilt Simplay by thinking in systems, not features.
1. Learning System
This is the heart of Simplay.
- YouTube Transcript API pulls raw text
- Gemini processes it
- Output is normalized into: Summary, Key takeaways, and Structured content
This forced me to think about prompt quality, not just API calls. Bad prompt = bad product. No amount of UI polish fixes that.
2. Authentication System
I kept this intentionally boring.
- Google OAuth for login
- JWT for session handling
- No custom password system
Why? Because auth is not where you should innovate unless you’re building auth itself. Google OAuth + JWT = reliable, predictable, done.
3. Dashboard & State Management
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.
Why I chose this tech stack#
People love overcomplicating stack decisions. Here’s my logic:
Frontend
- React (Vite): Fast dev server, no nonsense
- Tailwind v4: Speed > perfection
- Framer Motion: Micro-interactions matter more than people admit
- Lucide Icons: Clean, consistent, done
I wasn’t trying to invent UI paradigms. I was trying to ship.
Backend
- Node + Express: Predictable, flexible
- MongoDB: Schema evolves with the product
- Zod: Runtime validation > trusting inputs
- Rate limiting: Because AI APIs are expensive
And yes, people will say: "Why not Next.js full stack?" Because I wanted clear separation, not magic.
AI integration: the hard part#
Calling Gemini is easy. Making its output usable is not.
Problems I faced:
- Inconsistent responses
- Too verbose summaries
- Hallucinated sections
- Poor structure
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.
UI decisions that actually mattered#
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.
What Simplay taught me#
This project didn’t just teach me tech. It taught me that:
- Shipping something imperfect beats planning forever
- AI is a tool, not a shortcut
- UX is about restraint, not creativity
- Most “features” are distractions
- Clarity beats cleverness every time
If you’re building something similar#
Here’s your homework:
- Pick one real problem, not ten
- Build the smallest version that solves it
- Treat AI output as untrusted input
- Ship early
- Let users tell you what’s broken
Most people never get past step 2.
Final thoughts#
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. 🫡