Case study 01, pre-launch

Muksu
Menot

The assistant at the centre of this product runs entirely on the parent's phone. No conversation about a child ever reaches a server. A privacy-first planner for family life, built in one season by three people.

AuthorJuan Coleman
Founder, Triple Pepper
RoleProduct design, product management,
frontend, AI integration. Independent lead.
TeamThree-person founding team:
data engineering, product strategy, and me
StatusVersion zero
Quiet go-live, autumn 2026

Context

A studio thesis, tested on a real product.

MuksuMenot started as a test of a thesis. While setting up Triple Pepper, I wanted a project that would prove the studio's whole stack in one build: product strategy, product design, product management and serious AI integration, not a demo bolted onto a landing page.

The gap found me. Every summer, parents across Helsinki, Espoo and Vantaa run the same gauntlet: dozens of council sites, club pages and camp providers, none of them speaking to each other, all of them structured for the organisation rather than the family. There was no single place to plan a child's season.

So the brief became: a calmer way for families to find the right activities. Discovery and comparison in one place, with an AI assistant, Mia, doing the matching instead of the parent doing the searching.

MuksuMenot homepage: Discover what childhood could be, with the Ask Mia input
mm-hero.png
Fig. 01  MuksuMenot landing page. Parents describe their child to Mia in one sentence, or browse the full directory

The decision underneath

The AI runs on the parent's phone, not on ours.

Mia is the assistant a parent actually meets. Describe your child in a sentence and she returns a shortlist. She does all of that in the browser, on device, and no conversation with her ever leaves the phone.

That was settled before the interface existed, and it cost us things. An AI planner gets better the more it knows about a child, and this one holds nothing: no accounts, no child data, no bookings, no payments. Every feature that would have needed a server to remember a family was cut against our own roadmap.

Most of what follows is the consequence of that one call: what the product does, what it refuses to do, and what a three-person team had to build to keep the line under commercial pressure.

My role

One seat, several hats.

MuksuMenot is a three-person founding team with unusually clean seams. Stefan, our data engineer, owns the pipeline that gathers and enriches activity data. Andras, our product strategist, owns market thinking, partnerships, and the governance questions that keep a children's product honest. I hold the third seat: product design, product management, frontend engineering and brand, plus the marketing plan and the operating rhythm that keeps three part-time founders pointed the same way.

In practice that means I am the person who turns decisions into shipped interface, and meetings into decisions. Independent lead on everything the user touches; equal partner on everything the company decides.

What I did

Everything between the data and the parent.

The brand and identity, from name to logo to the visual system. The entire frontend: search, filters, an interactive map, a season calendar, per-listing pages generated for search engines, and full Finnish and English language support. Mia, the on-device assistant that turns a sentence about your child into a shortlist.

Around the product: competitor and market analysis, the marketing plan, the privacy policy and legal groundwork, and the team's internal control centre, a private dashboard that renders our decisions, roadmaps and meeting notes from the repositories themselves.

The Discover view: filtered activity list beside a map of Greater Helsinki with venue pins
mm-sorted.png
Fig. 02  Discover: every camp, club and event in one list, filtered by interest, age and area, mapped by neighbourhood

What I used

Deliberately boring technology, seriously applied.

The product frontend is a single, dependency-free vanilla JavaScript application. No framework, no build complexity beyond one small Node script that prerenders listing pages. Maps run on Leaflet and OpenStreetMap. Hosting is Vercel, with deploys triggered straight from git.

The internal dashboard is Next.js and TypeScript, reading markdown and the GitHub API. Nothing in it is editable; the repositories stay the single source of truth.

Where the AI actually is

AI-native where it compounds, human where it counts.

"AI-native" is doing a lot of work in most portfolios, so here is precisely what it means on this product, person by person.

Stefan, data and AI engineering. The catalogue exists because of an AI-heavy pipeline: thousands of records scraped from public sources, then classified, translated and normalised by language models, with quality checks at every stage. The same discipline extends to security: the catalogue is served from a database with server-side queries, so the dataset cannot be bulk-harvested from the client.

Me, AI-native product practice. I run the build the way I believe product teams will run within a few years. AI agents do my research legwork, competitor analysis and documentation upkeep, and every weekly call is transcribed and distilled into written decision records automatically. What ships is reviewed by me, decided by us, and owned by a human, every time. The result is one person covering design, code, brand and company operations at a pace that used to need a team.

Andras, privacy, security and compliance. Every AI claim and data practice gets pressure-tested before it reaches a parent: what we may hold, what we may say, and what we must never collect. His standing challenge, "prove it or do not claim it", is why the product tells parents to confirm details with organisers instead of pretending to a verification we do not perform.

And Mia, the assistant parents actually meet, is the one place we chose to add no AI at all on our side: she runs on device, as above. On a product about children, the most advanced decision we made was where not to use it.

Strategic choices

Decide what the product must never do.

The defining call was made early and held under pressure.

An AI planner gets better the more it knows about a child. It is also exactly the kind of product that must know as little about a child as possible.

Privacy first, permanently. No accounts, no child data, no bookings, no payments. Discovery only; registration happens with the organiser. We cut scope against our own roadmap to hold this line, and we do not claim verification we do not perform: every listing tells parents to confirm details with the organiser.

Launch as credibility, not as revenue. A directory is a business card. It earns partner conversations, search presence and trust before it earns money.

Niche first, staged rollout. Go where the data is strongest and a specific parent is genuinely served, then widen. A generic launch that half-serves everyone was the option we declined.

Free channels only. The market research showed organic search and word of mouth decide this category. There is no advertising race to lose, so we did not enter one.

The Compare view: three saved activities side by side with category, provider, ages, dates, price and language
mm-worlds.png
Fig. 03  Compare: saved activities side by side, each row asking the parent to verify details with the provider

How it went

The plan survived contact with reality by changing.

Built through spring and summer 2026. The catalogue grew from a few hundred records to well over a thousand as the pipeline matured and one-off events joined camps and clubs. Search moved through three generations, ending with a guided, filter-first flow because tests kept proving that parents want fewer, better results, not a longer list.

Reality intervened twice. Competitors surfaced in the space while we were pre-launch, which forced a sharper answer to "why us" and shifted the roadmap toward what nobody else covers. And the honest economics of the sector, where the volume layer is grant-funded associations, killed several tidy monetisation ideas on contact. Both were uncomfortable. Both made the product better.

Mia's screen: an illustrated assistant with the prompt Tell me about your child
mm-how.png
Fig. 04  Mia. Describe your child in a sentence; the matching runs on device and the conversation never leaves the browser

One operating picture

How six disciplines fit in one small team.

Legal compliance, privacy, design, product management, engineering and technology strategy do not coordinate themselves, and a three-person team cannot afford a coordination layer. The strategy that worked has three parts.

Constraints go first, not last. Privacy and legal are design inputs, decided before the interface exists. GDPR shaped the data model; the disclosure rules shaped the copy; the decision to never hold child data shaped the architecture. Nothing waits for a compliance review at the end because the compliance is load-bearing from the start.

Decisions live as files, next to the work. Every binding choice is written down as a short decision record in the repository it affects, with its context and its consequences. Meeting recordings are distilled into structured notes: what was decided, who owns it, what stays open. Anyone, including the AI agents we work with, can read the current truth in one place.

One dashboard renders it all. The internal control centre reads those files and the repositories and shows the whole picture: company decisions, each product's roadmap, what is outstanding, and a meeting agenda generated from the actual state of the work rather than from memory. Nothing in it is edited by hand, so it is never out of date and never argued with.

The result is that a designer's constraint, a lawyer's requirement and an engineer's architecture live in the same system, in plain text, owned by the people doing the work.

Outcomes

A real product, a real company, a working system.

A live catalogue of well over a thousand camps, clubs and one-off events across Helsinki, Espoo and Vantaa, in two languages, with an on-device assistant and per-listing pages built for search. A holding company structure with MuksuMenot as its first product. And an operating system for the team that turns weekly calls into recorded decisions instead of vibes.

Just as importantly: a set of things we proved we will not do, held under real commercial pressure.

Where we're at

Pre-launch, on purpose, with the gate defined.

The product is feature-complete for version zero and running privately. The launch gate is technical rather than emotional: the catalogue is moving to server-side delivery, which improves Finnish-language search and protects the data before it goes fully public. The team meets weekly; the next recalibration settles marketing and rollout order.

Releasing into the wild

Quietly first, loudly when it counts.

The release strategy respects how this market actually breathes. Demand arrives in seasonal windows: club enrolment in late summer, camp booking after new year. So the site goes live quietly, indexing accumulates, early users shape the rough edges, and the loud moment is saved for a season when the catalogue can back the promise. Launching softly is not hedging; in a word-of-mouth market you only get one first impression, and we intend to spend it well.

Reflection

What this proved about the studio.

Three people, six disciplines, one season. The trick is not working harder; it is building the system that lets a small team behave like a large one, then trusting it.

The most valuable design skill on an AI product is deciding what the AI must not do.

And the most valuable management artefact is not a plan. It is a written decision that everyone, human and machine, can read.

Have a product to ship?

Let's build
something meaningful

Start a project →