Product Design · UX Research · Game Design · Full-Stack Engineering
A lo-fi music companion with a spirit collection game. It rewards you for doing nothing.
The Spark
I've always loved games — especially Pokémon — and cozy gaming experiences. I'm also the kind of person who has a lo-fi stream running in the background of basically everything I do. At some point I thought: what if the music could give me something back?
Not in a productivity-app-that-guilts-you way. More like a quiet little world that grows while you work. You listen, eggs appear, spirits hatch, and your village slowly comes to life. You don't have to pay attention. That's the whole point.
I also wanted to teach people about Yoruba culture through the game — the spirit names, the lore, the world-building. Games are one of the best ways to introduce someone to a culture without making it feel like homework.
Problem
Every idle game, every Tamagotchi, every gacha loop — they all eventually guilt you into opening the app. That's the opposite of what a study companion should feel like. The core tension: game mechanics demand attention, but lo-fi culture is about letting go of it.
Our hypothesis: if progress happens while you study — not instead of studying — the game and the music can reinforce each other. Reward presence, not attention. Make the game work because you're ignoring it.
Research
I led competitive analysis across lo-fi streaming platforms and idle games, conducted interviews with college students about their study habits, and worked with the team to map the emotional arc of a typical study session — from "locking in" to "burned out background noise."
Core Loop
Ehoro Village is built around a single idea: reward presence, not attention. You open it, press play, and let it run. The app does the rest.
Sign in → Meet Professor Mowang → Pick your first spirit
Design Philosophy
Every design decision in Ehoro Village comes back to one principle: don't steal people's time. Modern apps are built to keep you scrolling, tapping, engaging. Ehoro is the opposite — it's designed to sit quietly in the background while you do your actual work.
That constraint shaped everything. The UI is a sidebar, not a full-screen takeover. The game loop runs on timers, not skill checks. There's no FOMO mechanic, no daily login punishment. If you miss a day, your spirits are just a little sleepy when you come back. That's it.
"The dark theme isn't an aesthetic choice — it's a design decision. The app is meant to run alongside whatever you're actually doing. A dark interface disappears into your workspace instead of fighting it."
Light theme exists too, styled like warm parchment for daytime vibes. The whole visual language — 19 custom sprites, muted tones, no saturated colors — is designed to feel like a cozy study room at midnight.
Responsive on mobile · Items tab with hatchery, ingredients, and crafting
Design Process
I designed a progressive disclosure system where the game layer reveals itself gradually. New users start with just music and a starter spirit — no menus, no dashboards, no overwhelm.
I mapped 7 primary views: Player, Village, Hatchery, Expeditions, Buildings, Spirit Detail, Crafting. Designed the spirit system — 6 types, 3 evolution stages, 15 passive traits across expedition, growth, and affinity categories. Worked with the team to balance the economy so casual listeners (1 hr/day) feel progress while dedicated users find depth.
Designed guided onboarding that teaches mechanics through play: choose a starter spirit → listen → earn first egg → hatch it → discover the village. Each step unlocks naturally — no tutorial overlay. Guest mode lets users try before committing to an account.
Led the creation of 19 custom sprites across 6 spirit types and 3 evolution stages. Established the "cozy study room" visual language — dark-first, warm parchment light theme, no saturated colors. Spirit names and lore draw from Yoruba culture, making the world-building an entry point for cultural discovery.
Designed 5 building types (Café, Dojo, Library, Garden, Studio) with 3 upgrade tiers each. Created 3 expedition locations with difficulty gating tied to spirit evolution. Balanced material drop rates and upgrade costs through iterative playtesting with the team.
Ran testing with target users. Identified cognitive load issues in the crafting flow (too many ingredients visible at once) and expedition selection (unclear spirit eligibility). Fixed through progressive filtering and inline eligibility indicators. Shipped with three auth methods and deployed live.
Design Decisions
The Hard Parts
This wasn't a project that went smoothly. We went through 24+ development sessions, multiple database migrations, and a debugging saga that taught me more about production systems than any course could.
After deploying V2.0, all 8 new server functions returned 404 errors. Expeditions, pills, cultivation — everything broke. Turns out PostgREST returns 404 for runtime SQL errors, not just missing functions. The actual bug? We were using JSONB operators on a native PostgreSQL array column. Took 6 SQL patches to fix.
After multiple sprint iterations, column names and constraints were inconsistent. A CHECK constraint on the emblems table only allowed 3 types but the app had 5. Every new feature required verifying the actual schema before writing any SQL.
V1.0 stored game state in localStorage — no validation, easy to cheat. V2.0 moved everything to server-side RPCs with Row-Level Security, rate limiting, and XSS sanitization. The migration broke most features temporarily, but the app is now production-ready for real users.
The Supabase backend — healthy, running, ready for ~1,000 concurrent users
Process Innovation
We used Claude as a development partner throughout this project. But here's the thing — AI doesn't remember your last session. Every new conversation starts from zero. So I wrote a manifesto.
The manifesto is a living technical document that we carry into every AI session. It has the database schema, the coding rules, the design philosophy, the session history — everything an AI needs to pick up exactly where the last one left off. No wasted time re-explaining context.
"The manifesto isn't just documentation — it's a collaboration protocol. It grew from a one-page overview to a detailed technical spec with 12 sections, session logs, and explicit rules for what AI should and shouldn't do."
This ended up being one of the biggest lessons from the project. The document IS the product — the code just implements it. I've since applied this approach to other projects and it's become our standard methodology for AI-assisted development.
Outcome
Ehoro Village is live and playable. Not a prototype, not a Figma file — a real product with real users.
Takeaways
What's Next
Ehoro Village is live and playable right now. We're actively working on adding original lo-fi music (I make beats — so this one's personal), expanding the spirit roster, and refining the monetization model so the game stays accessible to everyone regardless of income.
The target? First 100 real users. College students ages 17–20 who already have lo-fi running while they study. If we can make them close one other tab and open Ehoro Village instead, we've won.