Kiddosy

Context and business problem

Kiddosy started about four years ago with a first team. In October 2024 the project got into Hub of Talents, a start-up acceleration programme. The first team fell apart before joining it, so I built a new, bigger and better team of four.

The problem we set out to solve: finding a good after-school activity for a child is scattered across social media, word of mouth and individual websites, while small organisers still manage bookings and payments by phone and messenger.

Users and their goals

Two sides of the same booking, each with its own experience:

• Parents: search for activities, compare them, book and keep track of bookings.
  • Goals: find something nearby, at the right time and for the right age, without calling around. Pain points: no single place to compare offers, unclear availability and price.
• Organisers: manage their offer, groups, calendar, clients and incoming bookings.
  • Goals: fill groups and spend less time on admin. Pain points: booking requests and parent questions arrive through too many channels.

Constraints

• A start-up team of four; I cover operations, product and design at once.
• Two-sided: every flow has to work for parent and organiser.
• Limited budget before launch, so research and design had to focus on what delivers the most value first.

My role and responsibilities

• Co-founder: operations, product and setting the overall direction
• Product Designer: research and UX/UI for both roles, desktop and mobile
• Built the Kiddosy design system from scratch
• Built the AI workflow the team works in (see below)
• The rest of the team of four: two developers and a backend developer; I also cover the business side.

Process and key decisions

1. Discovery and research

Several large-scale quantitative surveys and at least 50 qualitative studies with the target group. The insights drove the design and the prioritising of what delivers the most value.

The insight that changed the product most: instructors (for example language teachers) often don’t enjoy dealing with the parents of the children they teach. The back-and-forth messages and reaching agreement cause a lot of frustration.

2. Definition

I turned the research into two role-based journeys, parent (search → offer → booking → my bookings) and organiser (dashboard → calendar → groups → bookings), prioritising what unblocks a first booking.

3. Ideation and design

AI is built into this stage: fast layout variants, coded prototypes and design review by agents. I built a multi-agent harness for Kiddosy (agent roles, quality gates, independent evaluation and handoffs), plus Claude skills for design: design review, UX/UI audits, predictive heatmaps and design-system consistency checks.

4. Design system

I built the Kiddosy design system from scratch rather than starting from a library such as shadcn/ui or Material: a custom, scalable system fitted to the product.

Decision: custom tokens and components.

Why: the same components have to serve two very different roles: a browsing parent and an organiser running operations.

5. Validation

AI output never ships on its own: I check it against the qualitative research, heuristics (Nielsen, WCAG, design-system rules), the harness’s independent evaluation and team reviews. We test continuously as we build; the product is still pre-launch.

6. Delivery

Kiddosy is at the final stage, just before launch.

Solution

The key screens, for both roles, on desktop and mobile:

• Search: location and radius, keyword, date, time and child-age filters, category tabs, and a list next to a map.
• Activity details and booking.
• My bookings.
• Organiser dashboard: operational priorities first: booking requests to accept or reject, with a reply deadline, next to parent messages.
• Group calendar.

Decision: the organiser’s first screen shows what needs action now (pending bookings, unanswered messages) instead of charts.

Why: response time decides whether a parent books.

Outcome and impact

• Kiddosy is just before launch, so there are no usage metrics yet.
• A research-backed product for two roles, a custom design system and an AI workflow I also reuse (including for this portfolio).
• Accepted into the Hub of Talents acceleration programme (October 2024).

What I learned and what’s next

• Rebuilding the team taught me that a product survives on the team, not on the idea.
• Next: launch, then measure the first-booking funnel and organiser activation, and feed the data back into the backlog.