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 structures messy brain dumps into a queryable backlog using an AI chat interface.
Role
Solo Designer / Builder
Stack
Claude (product thinking +
prompt engineering +
prototyping) → Lovable
(React/Vite build) → Vercel
(deployment) + Microsoft
Clarity + Tally
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 appended at the end of every response -
four action types only, one block per message - because it made the AI's database writes
deterministic and auditable. 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.
ALONSO ROSADO
AI-first Product Designer shipping full
products, end to end.