At 8:47 p.m., I ran out of bedtime story ideas.
My kids wanted one more story about their preferred characters, my grandpa. But this time my brain just want to go offline.
I thought I shouldn't be alone with this problem, so since I'm a builder, I started thinking of a solution.
I decided to build the thing I needed to create engaging stories for my kids when I'm not in the mood of telling the stories by myself.
This little idea became Lumio — a personalized AI bedtime story app. This post is about the product decisions and how I built it.
The constraints that actually shaped the architecture
Before picking any tech, I had one hard constraint: I am a solo developer with multiple projects and as you can tell I have kids that demand great stories:
- No separate mobile codebase. I will not maintain two story experiences.
- No "we'll figure out mobile later." Parents live on their phones. Mobile-first or don't bother.
Everything downstream followed from that.
Why Next.js App Router specifically
App Router maps cleanly to how Lumio is actually structured as a product:
- Public marketing pages
- Auth boundary
- Nested signed-in routes (profiles, story creation, saved library, playback)
- API routes for work that shouldn't reach the client
The old Pages Router would've had me shimming things together. App Router let me model the product's actual shape — public shell, authenticated interior, server-side work at the edges. One repo, one deploy pipeline, iteration without context-switching between entirely different mental models.
PWA before iOS, intentionally
The instinct for consumer apps is "ship iOS first." I went PWA first, and I'd do it again.
Reasons:
Feedback loop speed. No App Store review cycle. I can ship a fix, and parents have it the next time they open the browser. In beta, that matters enormously.
Installation without commitment. A parent can try Lumio from a link, install it to their home screen if they like it, and never deal with a store.
One codebase actually means one codebase. The PWA is the product. The iOS app is a shell around it. I'm not maintaining two story generators or two playback UIs — just one web app that happens to also run in a native wrapper for families who want App Store discoverability.
The part that wasn't about APIs at all
Here's what I expected to be hard: wiring together generation, audio pipelines, auth, storage.
The technical integration was maybe 30% of the work. The rest was a different kind of problem:
- How do you tweak the prompt for the language model so the output is calm, age-appropriate?
- How do you design a "describe tonight's story" input that doesn't require creative energy from someone who has none left?
Getting the tone right took far more iteration than getting the pipeline working.
What's in beta right now
The current build handles:
- Kid profiles with age and interest context fed into generation Freeform story prompts ("something calm with a dragon who's scared of the dark")
- Personalized story generation — characters and places from the child's actual life
- On-screen reading or audio playback
- Saved favorites and a replay playlist
- Narration in your own voice (so bedtime still sounds like you)
- Multi-language generation
I'm currently focused on reliability, onboarding clarity, and making story creation feel lighter (not on adding more features).
Conclusion
Building this app so far has been real fun! Not just the technical implementation but the fact that my kids love these stories. And I'm getting similar feedback from other parents who have been testing it in the past weeks.
You can try the beta at lumiostories.com. Feedback from parents are always welcome!
Top comments (0)