Pet · Product · 0 → 1 · 2026
Lumos — bedtime stories
Built an end-to-end clickable prototype of the whole funnel (landing → personalisation → generation → payment → narrated series) and a calibrated prompt engine. Preparing to launch.
TL;DR
An end-to-end prototype of a bedtime-story ritual — from discovery and a brand system to a clickable narrated prototype with a designed admin OS
- 01Designed the product from discovery and AJTBD segments through RAT, PRD and a funnel with built-in analytics
- 02Built a clickable end-to-end prototype (vanilla JS, no build step): landing → form → free episode → Telegram bridge → mocked ЮKassa payment → 5-episode series + upsell
- 03Designed a Story System and an Admin Product OS — a quality, safety and operations layer for AI-generated content
PLATFORM
ROLE
PLATFORM
TIMELINE
STATUS
The idea
Children aged 3–7 are often afraid of the dark, and bedtime turns into a daily struggle. Lumos's hypothesis: a personalised 1–2 week series of bedtime stories where the hero resembles the child and gradually overcomes the fear — not a one-off story, but an evening ritual. Personal goal: test the skill of solo-launching a digital product end to end, from research and hypotheses to a working prototype.
Discovery, market and AJTBD segments
Before writing any product code, I ran a discovery phase: mapped the market for personalised children's books and AI bedtime stories (including products like Loona and Tinker Tales), defined the parent's Big Job — "help my child end the day calmly and predictably" — and broke it down into 5 core Jobs To Be Done. Based on AJTBD I identified parent segments, from "evening chaos, need a quick ritual" to "looking for developmental content with morals, without lecturing". This research later shaped not just the feature set but the tone of voice — moving away from "AI generator" language toward "family ritual" language.
RAT → PRD → funnel with analytics
I validated the key assumptions with a Riskiest Assumption Test before writing any product code: are parents willing to pay for personalisation, is a "free episode" enough to demonstrate value, and does Telegram work as a delivery channel? Based on the RAT, I put together a PRD and a three-step funnel: web landing → free episode → bridge to Telegram → paid series. The prototype was instrumented with analytics events from day one (cta_click, free_episode_opened, audio_play, lead_bridge_click, checkout_started, payment_success, episode_opened) to see exactly where users drop off.
Prototype: landing → form → series → narration
I built a clickable end-to-end prototype in plain vanilla JS, no build step: a landing page with the offer, a personalisation form (child's name, age, favourite toy, fear topic), a free narrated episode, a bridge into a Telegram bot, a mocked ЮKassa payment, and access to a full 5-episode series with an upsell for the next topic. The prototype runs entirely on mocks — no real AI API or payment gateway — but reproduces the real user journey from first touch to repeat purchase.
Prompt engine and reference demo series
To make the prototype feel alive rather than a stub, I built and calibrated a story-generation prompt engine: an input-slot structure (name, age, topic, favourite toy, friends), length and pacing rules, and ~5 minutes of narration per episode. Based on it, I produced a reference demo series of 5 episodes about a girl, Masha, who gradually overcomes her fear of the dark — used both as a quality benchmark for future AI generation and as a live example inside the prototype.
Story System: from a generator to a system of rituals
As I worked on the content, it became clear that a prompt engine alone wasn't enough — the product needed a system. I designed a Story System: an episode formula (recognition → gentle distance → small challenge → hero's action → warm return), a 5-evening series structure with distinct roles per evening, age-band rules for 3–4, 5–7 and 8–10 year-olds, personalisation field tiers (required / strong / sensitive), and a "moral without moralising" technique with before/after examples. I also defined safety rules — forbidden promises, "red zone" topics, and a soft-refusal formula — plus a 10-criterion quality rubric with a minimum score of 16/20 and mandatory 2/2 on safety and IP.
Admin Product OS: an operating system for the product
To make an AI-native product actually operable, I designed an Admin Product OS — an operating system for the product built on top of the Story System. Information architecture: Overview, Funnel, Users, Child Profiles, Topics, Series, Episodes, Safety Review, Payments, Support, Experiments, Operations. I defined content / user / risk statuses, roles (Owner, Content Editor, Safety Reviewer, Support, Agent), UI principles (desktop-first, tables over cards, restrained colour-by-function), and a staged rollout — from upgrading the current admin with no DB changes to adding a metrics dashboard, content operations, and payments/support.
Metrics, insights, what's next
Key insight: the product's value isn't driven by generation quality — it's driven by the feeling of a personal evening ritual, which means AI needs to stay invisible. Current status: a working clickable prototype on mocks, instrumented with analytics, with a reference demo series and a designed Story System and Admin Product OS. Next: connect a real AI API and payment gateway, implement the updated client / bot / Mini App UI per the brand guidelines, and launch the first cohort targeting 5–15 sales per week.