MATS: AI SHIPPED PRODUCT · MOBILE
Note-Taking Tool For Martial Artists
Every technique you learn on the mat is gone by morning; MATS is a post-training logging system that turns messy brain dumps into something you can actually search and build on.
ROLE
Solo Designer / Builder
STACK
Claude → Lovable → Vercel + Microsoft Clarity
TIMELINE
3 weeks
YEAR
2026
MATS - TECHNIQUES
THE CONSTRAINT
Built for the exact moment users are least willing to type.
Exhausted, on a phone, right after training; every extra tap is a reason not to log at all.
The core interaction happens when users are physically exhausted, on their phones, immediately after training. Every additional tap, field, or decision is a reason not to log. The AI chat had to be fast and forgiving enough to accept genuinely messy input; not cleaned-up notes, but "got submitted with an arm bar need to review gordon's escape instructional" typed with sweaty thumbs.
3 KEY DECISIONS
Three calls that kept the log fast and the data usable.
Each decision traded a familiar pattern for the harder one that fit how martial artists actually think about their training.
Delete on completion, not archive.
The alternative was preserving completed entries in an archive view; a common pattern in task managers. I chose deletion because MATS is an action queue, not a journal. Every completed technique staying in the list increases the cognitive load of scanning what still needs work. The tradeoff is real: one beta user lost a technique he wanted to reference later, which surfaced a genuine product tension between "tool for action" and "tool for memory." That tension is now a v1.1 decision, not a bug.
Constrained JSON action schema over free-form AI output.
The alternative was letting the AI respond conversationally and parse intent from natural language each time. I chose a strict JSON block at the end of every response - four action types only, one per message - so the AI's writes to the database were predictable every time, not just most of the time. Free-form output works in demos. It fails at 11pm when a user's note is ambiguous and the AI has to decide whether "worked the guard" means add a technique or advance an existing one.
Two modes with sub-tabs over a unified list.
The alternative was a single filterable list of all entries. I chose a hard split between TRAIN (pre and post-training workflow) and WATCH (instructional library) because the mental context is completely different; one is about tomorrow's mat session, the other is about a study backlog that spans weeks. Mixing them in one list with filters would have made the app faster to build and slower to use.
TRAIN and WATCH - SPLIT BY MENTAL CONTEXT, NOT ENTRY TYPE
THE AI-SPECIFIC INSIGHT
The AI failure mode here wasn't wrong answers; it was too much helpfulness.
“
Specialized tools often need speed and invisibility over transparency and confirmation.
The failure mode I hit wasn't the AI giving wrong answers; it was the AI being too helpful. Early prompt versions produced empathetic, conversational responses with approval gates before adding entries to the database. That pattern works for a general assistant. It's wrong for a post-training logging tool, where the user wants to dump information and trust that it was handled, not review a confirmation card.
The fix was explicit tone instructions and a hard schema constraint: act first, confirm in one line, never ask. The broader principle is that LLM default behavior optimizes for user trust in the general case.
OUTCOME
Unprompted adoption within 72 hours of shipping.
72 Hrs
UNPROMPTED BETA ADOPTION
Two beta users logging real training sessions within 72 hours of deployment; without a prompt from me.
3 Weeks
CONCEPT → SHIPPED
Solo, end to end: product thinking, prompt engineering, build, and deployment.
Two pieces of unsolicited feedback in the first week: one bug report (line breaks not preserving) and one fundamental product challenge (deletion vs. archive); both surfaced real design decisions I had documented but not tested.
The TODAY tab - the pre-training game plan feature - was not discovered or used by either beta user without explanation, which means the onboarding is not doing its job regardless of how well the feature works.
ONE THING I'D DO DIFFERENTLY
Test onboarding first, build it last.
Build the onboarding last but test it first, I wrote three screens that explained the product accurately and none that communicated what to do in the first sixty seconds.
MORE CASE STUDIES
