When I get an app idea, I can usually imagine far more features than I need. The interface, the phone version, the clever connections. I can spend a lot of time building before finding out whether I actually want to use it.
In this Homebrew Club episode, I show Jim the filter I’ve started using, and my own notes system as the example.
Three stages, with permission to stop
First, work with the idea in the terminal. For my builds, that means a project with Claude Code and the simplest useful data and logic. I can ask it to capture something, change it, or retrieve it without first building an interface. The point is to discover whether the core job is useful.
Second, add the smallest interface that fits where you use it. A notes tool might need a phone surface because ideas don’t wait until I’m at my desk. Add that when location or interaction is the problem, rather than because a proper app is supposed to have it.
Third, build the complete application. By then, I want evidence from using it for a couple of weeks. What do I actually return to? Where does the current version get in the way?
Most of my ideas can stop at the first stage. Some useful tools can stay there indefinitely.
The real job of my notes system
I had notes in several places, including voice recordings I would have to replay to remember what they contained. Capturing a thought didn’t mean I could find it when it became useful.
The approach I borrowed from Zettelkasten was to capture small ideas and connect them. My real test was retrieval: could I start a project by asking what I’d already thought about that subject?
In the episode, I ask for notes about building things for my kids. It brings back ideas I’d forgotten, along with broader principles that apply to those projects. That gives the next conversation a running start.
I took a detour first
I’d already built a Telegram route for capturing notes. Then I went back to the terminal because it did enough of what I needed. The framework came from noticing my own overbuilding, not from avoiding it perfectly.
The personal system on screen stores notes in Supabase and has context from my other projects. The public phase-one skill is a simpler version: local Markdown files, tags, links, and a Python command-line helper. It doesn’t require that database or reproduce all my personal integrations.
Borrow the test before borrowing the tool
The three-stage worksheet works even if you haven’t used a terminal. Start by describing one useful input and output. Try a manual or chat version before installing anything.
If the notes use case fits, the build page explains the released skill and what you would need to use it. The first success to look for is an old thought helping with something you’re doing now.