SmallHeroes
Personalised resilience storybooks for children · Hebrew · גיבורים קטנים
A parent pays for a book that doesn't exist yet.
Visit the live SmallHeroes site
A resilience story, written around one specific child.
SmallHeroes makes illustrated, narrated storybooks in Hebrew for a child going through something hard — night fears, a new sibling, a medical appointment, social difficulty, a big move, big anger. The parent fills in a few small details and a photo; the child becomes the hero of the story, and a companion animal goes through the difficulty with them.
The story doesn't fix anything, and doesn't pretend to. It meets the child inside the hard thing, shows them they're not alone in it, and hands them small, concrete steps they can actually take — the same steps the hero takes on the page. Not therapy; a story written with care, built to be read again on the nights it's needed.
A spread from a finished book — Yuval's clinic visit, with Buni. Illustration on one page, the story on the other, narrated end to end.
I lead SmallHeroes across product definition, UX, visual direction, story rules, pricing and delivery. AI agents carry a large part of the implementation and production work, under my brief, review and QA.
The hard design problem isn't the book — it's asking a parent to pay ₪59–₪99, for their own child, for something that only exists once they have.
Consistency is the whole product.
Generative illustration is easy to make beautiful once. Across sixteen to thirty-two pages the child drifts — and so does the companion, the room, the light, the palette. The moment a parent notices, it stops reading like a book and starts reading like output. That single perception is the difference between a keepsake and a refund.
So the fix had to be structural rather than a better prompt: an approved visual contract per book, a reference locked per scene, an automated drift check before anything reaches a person, and a human approval on every book before it ships.
Here is one generated book, page after page. Same child, same t-shirt, same green wristband, same red shoes, same bunny, same clinic. Scroll it sideways — that's the test a parent runs without knowing they're running it.






Six pages from one generated book, in order.
The photo step is a product ethics question.
The obvious engineering answer is to validate the photo hard: reject anything dark, blurry, side-on, low-contrast or small. It produces better illustrations and a cleaner pipeline.
It also means a parent uploads a picture of their child and a form tells them it isn't good enough. Depending on skin tone and lighting, that rejection is not evenly distributed. I wasn't willing to ship it.
- 1The upload explains itself. Why a clear face helps, and that the photo is used only to draw the character — stated before you're asked for it.
- 2“Continue without a photo” is a primary button. Not a grey skip link in the corner. Going on without one is a real, respected path.
- 3The trade-off is written plainly. Without a photo the hero is drawn from age and gender, and won't look like your child. You can add one at any step up to payment.
Hebrew, right to left — shown on mobile because that's where the wording sits under the button. The only thing that actually blocks the flow is a file that can't be read at all.
Getting a child onto the page without writing a form.
A personal book needs a surprising amount of input: name, age, gender, the specific difficulty, what the child is like, whose voice reads it, how long the story should be. Ask for that as a form and nobody finishes it.
It's seven steps, one idea per step, phrased the way a person would ask. The first step is a single choice — which of six difficulties is happening right now — and each one comes with a companion, so the child has an ally before they have a story.
Later steps do the same thing to the parts that would normally be a form. Traits are chips rather than a text field, because “choose four words” is a much smaller request than “describe your child”. The narrator is picked by listening, not by reading a list of names. And the child gets a Power Card — the hero's four small steps, lifted out of the story so they leave the book with the child.
The Power Card, and the length step. Price appears as a running total from the first step, so the number at checkout is never a surprise.
Generation takes minutes. That's a design problem, not a loading state.
A parent has just paid for a book that doesn't exist. Then the product asks them to wait. A spinner in that moment quietly implies something has gone wrong.
The waiting screen names the child, so it reads as your book being made rather than a queue position. It gives explicit permission to leave — close the tab, an email arrives with the link — which removes the only real anxiety in the moment.
Behind it, failure is a designed path too. A page that doesn't pass the drift check is regenerated before anyone sees it, and during the pilot every book is reviewed by a human before delivery. The parent's version of that is simply: it takes a bit longer, and it arrives right.
Six companions, three lengths, eighteen books.
Each difficulty has one companion, and each companion has a fixed visual identity that has to survive every book it appears in — the same fox, in thousands of different children's stories.






- Three lengths. Bedtime story at 16 pages (₪59), adventure at 24 (₪79), fantasy at 32 (₪99) — launch pricing.
- Illustrated and narrated. Every book ships with full narration in a voice the parent chose, read in a personal reader rather than sent as a file.
- Two illustration styles. Whimsical or realistic, chosen by the parent, held consistent across the whole book either way.
- Human-reviewed. During the pilot, no book reaches a parent without someone approving it first.
AI handles parts of the execution. The product decisions stay human.
SmallHeroes is built through an AI-assisted workflow that spans software implementation, story generation, illustration and narration. It is the reason one person can work across all of it.
What I do is define the brief: the flow, the visual system, the story rules, the priorities and what counts as acceptable. Agents write a large share of the code and produce first drafts of the content. None of that output is treated as finished — it is reviewed, tested, sent back and revised before it becomes part of the product.
The same principle governs the books. Every story follows approved structural and emotional rules, built on resilience language — seen, not fixed; small steps, not magic — developed with an art therapist, with the site stating plainly that this is not therapy. Character references and page-level checks hold consistency, and during the pilot a person reviews every book before it is delivered.
Writing that boundary down, and designing a product that respects it, is the part no model does for you.
I own
- Product direction and priorities
- UX, UI and visual direction
- Story and content rules
- Briefs and acceptance criteria
- Functional and visual QA
- What ships, and when
Agents handle
- A large share of the implementation
- Refactoring and technical investigation
- First drafts of story text
- Illustration generation
- Narration production
- Repetitive production work
Status: pre-MVP, entering a supervised pilot. Eighteen catalogue slots defined, the generation and review pipeline running, and every book checked by a person before delivery.
Let's build something worth using.
Open to senior product design roles — especially where product, systems and AI meet.