I’ve shelved the language learning app for a few weeks. Not out of defeat, but because I hit a wall I couldn’t code my way through.
I was drowning in feature creep before I even had a functional product. When I finally forced myself to zoom out and look at what I’d built, I felt that familiar knot of confusion tightening in my chest. The kind you get when you’re three hours deep into a problem and realize you’ve been solving the wrong equation entirely.
I was tangled up in:
- User experience design that tried to be everything to everyone
- Feature bloat in what was supposed to be an MVP
- Responsive design challenges optimized for both desktop and iPad, when I should’ve been thinking mobile-first
The longer I stared at my screen, the clearer it became: I needed to strip this thing down to its skeleton and rebuild with intention.
I’ve Been Doing This Backwards
Here’s what I should’ve seen from day one: this is fundamentally a note-taking app for language learners. Two distinct core functions that I’d been trying to marry in a shotgun wedding.
The architecture was fighting me because I was forcing a monolithic approach when I needed modular thinking.
Build the robust note-taking system first: streamlined, lightweight, performant. Then layer in the language learning features as a separate concern.
My initial vibe-coded prototype turned into spaghetti code the moment I tried to interweave both feature sets simultaneously.
It’s like trying to build the foundation and roof at the same time. Technically possible, maybe, but architecturally insane.
The Reset: Building Like I Actually Know What I’m Doing
Starting next week, I’m going back to first principles. Time to clean up my scattered Apple Notes, consolidate my ideas, and implement actual priority-based development.
High-priority features that deliver core value. Medium-priority nice-to-haves. Low-priority “wouldn’t it be cool if…” features that belong in version 2.0.
Maybe it’s time I stopped romanticizing the “vibe-coding” approach and started thinking like the software engineer I’m supposed to be. That means:
- Creating a proper development roadmap with realistic milestones
- Implementing sprint planning to maintain momentum without burning out
- Setting up a Kanban board to visualize my workflow and identify bottlenecks
Building in public has been energizing, but I need to lean into it harder. More transparency about my experiments, more candid updates about what’s working and what’s spectacularly failing. Accountability breeds better code.
Technical Pivots I’m Making
Even though I’ve already committed to a brand name (which I’m still keeping under wraps), I’m reconsidering my technical stack and deployment strategy.
Right now, the homepage lives in Lovable, but I’m realizing I need to decouple the marketing site from the application itself.
It’s basic redundancy planning. If one goes down during an outage, at least the other stays functional. Your landing page shouldn’t crash because your app server is having a bad day.
I’m also wrestling with the visual identity. Should I follow established design patterns in the language learning space?
The Duolingos and Anki-inspired interfaces that users already trust? Or do I risk standing out with a bolder, more unconventional aesthetic?
Part of me worries that being too different might work against adoption. The other part knows that “just another flashcard app” won’t cut it. I haven’t landed on an answer yet, but I’m letting the UX research guide me instead of my ego.
What’s Coming
Expect more frequent updates from me, with tighter feedback loops, more honest reflections on what I’m learning.
This aligns perfectly with my million-dollar challenge, which I’ll be documenting alongside the podcast I’m finally launching now that the construction drilling in my building has mercifully ended. (Trust me, you’ll hear all about that saga in my next wrap-up.
Let’s see where this reset takes us.