
SONKEI: AI SHIPPED PRODUCT · MOBILE
Match With The Right Martial Arts Training Partners
Martial artists traveling to new cities have no reliable, trust-layered way to find vetted training partners.
ROLE
Solo Designer / Builder
STACK
Claude → Lovable → Vercel + Microsoft Clarity
TIMELINE
3 weeks
YEAR
2026

SONKEI - FILTERS
THE CONSTRAINT
Safety couldn't be a feature layered on top; it had to be the model.
Every design decision here was a trust decision first, and a feature decision second.
Sonkei couldn't treat safety as a feature layer added on top of a working product. Every design decision - whether users can message immediately, whether win/loss records appear, how many onboarding screens there are - was a trust decision underneath. That reframe changed everything that followed.
3 KEY DECISIONS
Three calls that built consent into the product, not around it.
Each decision traded the faster pattern for the one that respected what's actually at stake before two strangers train together.
Request-gating over open messaging.
Messaging unlocks only after both users accept a session request. Not a safety feature bolted on; a model of bidirectional consent before physical contact. It also changes behavior: a user who explicitly accepted your request shows up differently than one who just received a cold message.
Removed win/loss records from the data model.
Not just hidden; gone. A practitioner with a 0-0 record who is an excellent drilling partner shouldn't be filtered out. A practitioner with a 12-3 record who is dangerous to train with shouldn't be surfaced. The stats show Exp, Stance, and Belt. They communicate compatibility without rewarding the wrong behavior.
Vertical scroll over swipe cards.
Choosing a training partner is a multi-variable decision: discipline, experience, availability, location, belt rank. Swipe cards force a binary judgment before you have context. Vertical scroll lets you compare. Less exciting, more honest about what the decision actually is.
THE AI-SPECIFIC INSIGHT
The spec document isn't documentation; it's the design artifact.
“
AI-generated UI is locally coherent but globally inconsistent without explicit upfront contracts.
Working with Claude and Lovable surfaced this failure mode early. Each screen looked right in isolation. The problems showed up at the seams, navigation states that didn't match, spacing that drifted between flows, components that looked related but weren't. The fix wasn't better prompting; it was declaring a canonical state machine before writing a single prompt, and referencing it by name in every subsequent one.
The spec document isn't documentation. It's the primary design artifact.

SONKEI - PROFILE
OUTCOME
Testers understood it without instruction; and shared it unasked.
3 / 10
Shared Unprompted
Testers forwarded the link to someone else without being asked; the strongest validation signal on the page.
8 / 10
Completed Core Loop
Moderated testers completed the core loop without instruction.
3 Weeks
Concept → Shipped
Solo, end to end: product thinking, prompt engineering, build, and deployment.
Most-cited insight: availability overlap visualization reduced evaluation cost before any profile tap.
ONE THING I'D DO DIFFERENTLY
Travelers and local seekers aren't the same user.
I'd validate the use-case split between travelers and local seekers before building the feed; they have different retention curves and the product needed to account for both from the start.
MORE CASE STUDIES
