Building a practice tool that targets your weakness, not your strength
AI that refuses to do your work for you, so you flex the muscles that matter.
- Role
- Designer-builder
- Client
- Personal project
- Date
- Jun 2026
- Scope
- Product strategy, UI design, frontend engineering, AI integration
- Tools
Nextjs
Claude AI
Netlify
Tailwind CSS
Shadcn
Context
Working builders can prove execution, but judgement is sometimes the gap
Bootcamps hand you finished projects, and AI assistants generate briefs that target what you already know. The result is portfolios full of polished execution and nothing that says "I can think," nothing that shows you can push back, justify a cut, or make a hard call with incomplete information.
I used to be one of those people, thus, I built Flinch for me first.
The pivot
I rebuilt the loop so that you have to earn the brief
The original version of Flinch generated the brief for you. You'd describe your gap, and the tool would produce a fictional stakeholder, a problem statement, a fully-formed brief with constraints and acceptance criteria, all polished and quick. But it missed the point.
I ran myself through it and the brief was *too clean*, like I'd been handed something I would have had to fight to produce in real work. The simulation was skipping the part where you sit with a vague client, ask the wrong questions, miss something obvious, get pushback, and slowly build a brief out of the friction. That part is the skill, and executing afterwards is mechanical.
So I rebuilt the loop. Instead of generating a brief, the tool now generates a *problem drop*: a fictional stakeholder, a name, a role, a company, a short context paragraph. Deliberately incomplete, because that's how real briefs arrive. The user enters a discovery chat with the stakeholder, asks questions, takes notes, and writes their own brief in their own words. The brief goes to the stakeholder for review, who approves it or pushes back, and only after approval does the tool generate the plan and milestones.
The user earns the brief, and the tool's job is making earning it hard in the right ways.
What I made
Nine stages, all designed to push back where it matters
Flinch is a Next.js web app, and the loop runs in nine stages.
Profile
Stack plus the gap you want to close.
Problem drop
Fictional stakeholder, deliberately incomplete context.
Discovery chat
You interview the stakeholder, and a contact counter ticks up each visit, forcing each question to count.
Brief writing
Hid the interview on purpose, forcing the user to rely on their notes, because you don't flex this muscle if you can copy/paste everything.
Client review
Stakeholder approves or pushes back, and tone gets sharper if you go in circles, because real clients lose patience too.
Plan generation
Your approved brief becomes constraints, acceptance criteria, and milestones in your own words, so you can't disown the plan when you wrote what it's built on.
Milestone research
Open questions surface before you start coding, with notes captured in an append-only log because research is layered, not revised. A sidebar lets you go back to the stakeholder mid-build, because discovery doesn't actually end at discovery.
Milestones with comfort toggle
Fine or nervous, per milestone, with reflection at the end of each.
Completion
A mentor observation built from your nervous flags and reflections, recording how the run actually went.
Two design moves are doing most of the work.
The stakeholder refuses to be helpful
Default AI behaviour is to infer what you meant, summarise it, offer structure, and that behaviour is the enemy here. The stakeholder doesn't volunteer information, sometimes doesn't have data, and pushes back when you're vague. Ask "anything will help" and they reply *"that's a bit broad for me to know where to start."* Most prompting work tries to make models more helpful, but this needed the opposite.
The comfort toggle informs support, not difficulty
Each milestone has two flavours of support content (support_fine and support_nervous), both generated at brief creation. Lazy generation on toggle would mean the toggle just changes a label, with the nervous experience feeling slower and the two supports drifting toward near-identical text. The mechanic only works if both variants exist in the data model from the start. Nervous gets richer hints, more context, more hand-holding, while the challenge stays the same. Making nervous easier would let you route around the discomfort you need to face, which is the opposite of what Flinch is for.
Where it's at
MVP shipped, with a roadmap to improve
The MVP ships. The data contract holds. The mechanic works under self-testing.
Three things are pending, in priority order.
Cold run-through
With users who didn't build it, and already scheduled.
Supabase persistence
The current localStorage-only setup gives you one project at a time, gone if you close the tab at the wrong moment, which is why I deferred this until the loop had survived contact with itself.
Generated artefacts
The stakeholder talks about source materials (a churn report, an analytics dashboard, a competitor teardown) but no real artefacts exist, because real discovery is partly conversation and partly artefact archaeology, and Flinch trains the conversational half well, the artefact half not at all.
Live at flinch.netlify.app
