KnobSnobAI guides for music gear
A live product that turns dense music-gear manuals into plain-English guides and grounded chat. Designed by me, built with Claude Code as engineering partner. Live at knobsnob.app ↗.
- Solo-built, 0 → 1, live at knobsnob.app
- 43 variables, 12 components, 0 unbound
What does this knob even do?
As a former audio engineer and a hobbyist musician, I find myself coming across music equipment I love but don't fully understand. I see controls that explain nothing: what does 'activity' mean? What does 'error' mean? What does 'delta' mean? The answer is always buried somewhere in a manual, so I wanted an easy way to understand what my own gear does.
What was my hunch?
Audio people have no efficient way to store their manuals beyond simple storage solutions, let alone learn from them. If the friction of interacting with manuals was gone, it would keep the momentum of creativity going rather than halt it.
I went and asked an audio-focused subreddit how people keep track of manuals and the answers confirmed it, ranging from meticulous PDF folders to piles of unopened boxes. The strongest validation came from one response: uploading manuals to NotebookLM to ask questions about their gear.
Core features
Controls
This feature addresses the most important aspect of using gear: what does every knob, button and jack on the unit do, explained in the simplest terms. Search a control and get a plain-English explanation, the reference from the manual, and a fun tip on how to explore it.
Ask
This is the embedded 'Gemini Notebook' feature. Quickly ask questions about your gear from 'how do I save a preset' to 'how can I get this to sound like Mac DeMarco'. The option to bring in additional sources ie videos, files, or personal notes is available too.
Manual
Where the whole idea started: storing the manual to reference the actual source. The official PDF lives right next to the guide, so the source of truth is always one tab away. If the wrong manual is on file, report it, and a fix is generated and reviewed.
How do design decisions scale?
Rather than building out my designs in Figma like I have my entire career, I used Claude Code to build out the app's UI and UX in Figma using the MCP, and set up the design system that governs its components: 43 tokenized variables, 12 components with variants and exposed properties, and 7 fully composed screens, with every fill, stroke, radius and padding bound to a token. This allowed me to develop a foolproof relationship with Claude when it came to exploring features and future design decisions.
How did I pick which AI to trust?
To land on which LLM and model yielded the best results, I had Claude run an A/B test to find the right balance of API costs and quality of results. The final verdict was Claude Opus for generating the easy-to-understand guides, and Gemini 3.1 Pro for the chat feature.
What does 'built with Claude Code' mean?
I designed everything and made every product decision; where Claude Code came in was building the work stream and acting as engineering partner. With MCP wired to Figma, GitHub, Supabase, Vercel, Stripe and Search Console, the work was streamlined to be nearly effortless. The more nuanced part was using Claude agents to facilitate research and product tasks to ensure every product decision was informed and backed by existing insights.
What's proven, and what isn't?
37 guides are now in the catalog set up with SEO, 18 registered users, 62 saves, and a flag queue to make sure there's a proper pipeline in the case there's ever wrong information in one of KnobSnob's guides. What's next to measure: analytics including flag rate once traffic grows, whether people come back to their library, and guides per user. The initial model is designed, but whether it holds at scale is the open question.
A live, multi-user AI product with a real trust model, shipped by one designer.
- Live at knobsnob.app; 37 guides in the shared catalog
- Claude-built Figma design system: 43 tokenized variables, 12 governed components, zero unbound properties
- Moderation, progress UI, model selection and pricing all designed, not defaulted
- Public SEO pages that match the app, Stripe billing, freemium quotas
What I'd do differentlyThe thing that surprised me most is how much of an AI product is not the model. The model choice was a week of blind testing; the trust and moderation design and the wait were where the product got made or broken. Working with Claude Code as engineering partner also changed how I design: I now write behavior as I would explain it to a person, and the gap between the sketch and the working thing is a day, not a sprint. If I started over I would seed the catalog before building the moderation queue, because trust features are only useful once there is something to trust.