← All work
Case study 09 · Edtech · Marketplace
TutorKiwi.
One tutor, matched to your child. No profiles to scroll.
Case study 09 · Edtech · Marketplace
One tutor, matched to your child. No profiles to scroll.
Most tutoring sites hand parents a grid of profiles and a search box, then leave them to work out who fits their child's level, exam board and timetable. It turns a worried parent into an unpaid recruiter, and the choice usually comes down to price and a nice photo.
There's a second, bigger issue. A tutoring platform puts adults in regular private contact with children. Safety can't be a policy page; it has to be part of how the product works.
So the brief: understand the child first, make one confident match, and keep every lesson and message inside a space that's watched over.
Parents describe their child in about five minutes. TutorKiwi picks one vetted tutor by subject, level, exam board and shared free times, and shows exactly why. Asking for another match is always one click.
Family chats and in-lesson chat are checked for phone numbers, emails, other apps, meeting up, secrecy and off-platform payment. Nothing is silently blocked: a person reviews each flag and can clear, escalate or suspend.
Lessons run in a private video room with its own chat and file sharing. The video tool's built-in chat is switched off, so every word goes through the same checks, and parents can read along.
Students sign in with a username and PIN their parent sets, and their view never shows prices or payments.
No subscription to sell a nervous parent. Each lesson is paid on its own, priced in the tutor's currency, and the payments page shows what's due, what's paid and what's next.
The admin portal has seven access levels, from owner to analyst, so a support agent can't see finance and a finance lead can't read safeguarding flags.
A match only builds trust if parents can see why it was made. Every result lists the reasons in plain language: the subject and level, the exam board, the strengths the parent asked for, the times that work for both, and that the tutor is DBS-checked and ID-verified.
Underneath, matching allocates from the pool of approved tutors using those same criteria, rather than someone hand-picking every pair. That's what lets it scale without the quality dropping.
A parent who isn't sure can ask for another match with no questions asked. Each time that happens, it tells us what the matching got wrong.
The tempting design is to block anything that looks risky. But a blocked message teaches people to rephrase, and the platform loses the signal. TutorKiwi lets the message through and puts it in front of a person straight away, with the full conversation one click away.
Parents and children also get a private "Something not right? Tell TutorKiwi" button that opens an urgent support thread.
It also installs on a phone like an app, and shows a proper offline page when the signal drops.
TutorKiwi is live but still onboarding its first tutors, so these are targets, not results.
I designed and built TutorKiwi over a weekend, and made the product calls: one match instead of a catalogue, what safeguarding watches for, what a child can and can't see, who in the team can see what. Every change went to a preview first and only reached the live site once I'd approved it.
A set of 44 end-to-end checks runs on every change, including the ones that matter most: an outsider can't open someone else's conversation, and a child's view never shows a price.
"When the user is a child, trust isn't a feature you add later. It's the product."