WanderMoss

Notes

Working notesfrom the studio.

Short, specific write-ups of what we are learning while building. Three so far; more as the work earns them.

Three translucent pale-blue paths and a dotted cobalt plane rise toward a shared open space.
02 / Common groundA study in exploration

Why Trail is boring on purpose.

We cut autonomy before we added it. What twelve teams told us about trust.

James, Founder

When we started Trail, the obvious demo was the impressive one: give the agent a goal, watch it run, come back to a finished result. We built that version first. It lasted three weeks.

The teams testing it did not want a finished result they had not seen being made. They wanted to know what the agent was about to do, why, and how to stop it. One product lead put it plainly: “I don’t need it to be clever. I need to not be surprised.”

So we removed most of the autonomy. Trail now works in a loop that is almost dull to describe. It reads the goal the team wrote down. It proposes the next step, with the sentence in the goal that justifies it. It waits. When someone confirms, it carries that step through, shows the result, and proposes the next one. Nothing happens silently. If it cannot tell who owns something, it says so instead of guessing.

Three things followed from that decision.

First, trust arrived faster than capability. Teams let Trail take on more once they had seen it decline to act. The permission to be ambitious was earned by being predictable.

Second, the most valued message turned out to be “nothing to do.” A tool that can say there is no next step is a tool people believe when there is one.

Third, the routine parts are where the value is. Drafting the follow-up, gathering the three documents, checking the numbers match: these are the steps that disappear between “we decided” and “it happened.” Trail does not need to be brilliant to be useful there. It needs to be reliable.

We still believe the ambitious version is where this goes. But the path runs through boring, and we would rather walk it with twelve teams who trust us than sprint it alone.

What 100,000 bedtime stories taught us about voice.

Children forgive a flat plot faster than a strange voice. Three product decisions that followed.

Mina Okafor, Head of Design

MoonNest passed one hundred thousand stories this spring. We read a lot of them, and a lot of the feedback that came with them. The pattern that surprised us most had nothing to do with plot.

Children are generous readers. A story that wanders, repeats itself, or ends too soon still gets a request for another one tomorrow. What they do not forgive is a voice that sounds wrong. A narrator that pronounces their name oddly, or reads a scary line too brightly, breaks the spell in a way no plot hole does.

That changed three decisions.

We moved family-voice narration from a late-stage extra to the centre of the product. Within a month of launch it was the most used feature, and families who used it read together twice as often as those who did not. A parent’s own voice is not a nicer version of a synthetic one; it is a different product.

We rebuilt the story library around recurring characters. Generated stories can go anywhere, but a four-year-old wants the same blue dragon back. Continuity turned out to matter more than novelty, which is a humbling thing for a generative product to learn.

We gave parents more control before the story starts rather than after. Length, themes, what to leave out. The best AI features in MoonNest are the ones a parent sets up once and then forgets, because the story simply arrives the way they wanted.

None of this is specific to bedtime. Presence over polish, continuity over novelty, and control before the fact are the same three things the teams testing Trail keep asking us for. We are starting to think they are not product lessons but collaboration lessons.

Three questions before adding AI to anything.

The checklist we run on every feature, and the two features it killed.

Sofia Laurent, Product

With seven people, every yes is a no to something else. Over the last year we have settled on three questions that every proposed feature has to answer before anyone opens a design file.

Can we name the goal in one sentence? Not the feature, the goal. “Parents want to fall asleep next to their child, not next to a screen” is a goal. “Add a sleep timer” is a feature that may or may not serve it.

Does AI change the answer, or just the pitch? Plenty of ideas are better with a good template and a checkbox. We only reach for a model when the goal genuinely needs judgment, language, or variety that a fixed design cannot provide.

Can a real person use it within eight weeks? Not a demo. A person outside the company, doing the thing, without one of us in the room. If the honest answer is no, the idea goes back on the shelf until it can be smaller.

Two ideas we liked did not survive. A story marketplace, where families could share and sell their stories, failed the first question: we could not say whose goal it served without saying “ours.” An always-on assistant inside FantaLove that suggested what to say next failed the second: the conversation was already the product, and the suggestion made it worse.

Trail passed all three only after being cut down. The first version was a whole “company operating system.” The version that survived does one thing: it takes a goal a team has written and proposes the next step. That is a goal we can name, a place where judgment matters, and something twelve teams are using today.

The list of things we said no to is now longer than the list of things we ship. We think that is what a small company’s product sense looks like from the outside.

Continue

See what the notes are about.