Folk Software
Code that starts with "I wish this existed".
Last week I built a tiny tool called The Analogist. You paste in a dense concept and it generates increasingly unhinged analogies until one clicks. “Okay so RAG is like... a sommelier who can only recommend wines they’ve personally tasted in the last hour.” I made it because explaining AI to clients is an ongoing thing and I need to entertain myself in the process.
It obviously didn’t take very long. It was ugly at first. Then I made it nice looking. And it works.
A friend saw it, asked for a copy, and now a couple of other people use some version of it. None of us would have paid for this. No product manager would have greenlit it. It exists because I wanted it to exist. I wasn’t the only one but it wouldn’t have mattered if I was.
I’ve also made a CRM that works the way I work, a serendipity engine, a hype decay tracker, a draft graveyard and heaps more things.
I’ve started calling this folk software.
The songs of folk music emerged from communities rather than studios, passed around and adapted, never focus-grouped. Folk music didn’t disappear when recorded music arrived. It just stopped being the only option. For a while, if you wanted music, you either made it yourself or knew someone who could.
Software has been in its “recorded music” era for decades. If you wanted a tool, you either bought what the industry offered or you didn’t have it. The threshold for creation was high enough that almost everything had to be commercially justified. Will enough people pay? Can we get budget for this?
That threshold just collapsed.
Tools like Claude Code, Cursor, Replit mean the calculus is now simply: do I want this? The answer can be yes for an audience of one. And sometimes that audience will turn out to be more than just you.
There’s an idea in urban planning called desire paths : those unofficial trails worn into grass by people walking where they actually want to go, ignoring the paved routes (you’ve probably seen the JPG meme).
Eventually, smart planners pave over the desire paths instead of fighting them.
The best folk software works the same way. It’s not imagined from first principles or designed for an abstract user. It’s discovered through living. You needed something, you made it, you realised others walk the same path.
This is the opposite of product-market fit. It’s product-life fit that turns out to be shared.
Folk software has a particular character:
It’s small. Often a single file, a script, a workflow. It doesn’t want to be a platform.
It’s specific. It solves this problem, not problems in general. The constraints are what makes it useful.
It spreads through sharing, not marketing. Someone posts it, someone forks it, someone adapts it for their own situation. The lineage matters more than the brand.
And crucially: the creator is a user. Not a product manager, not a founder chasing a market. Someone who needed the thing and made the thing. The gap between those two roles has closed to zero.
Woodworkers have a concept called the jig drawer. A jig is a custom tool you make to help with a specific repeated task, holding a piece at the right angle, guiding a cut, spacing things evenly. Every woodworker’s jig drawer looks different because everyone’s work is different.
We’re all building jig drawers now. What will happen when millions of people have jig drawers full of small, specific, useful tools they made themselves?
I think we’re about to find out.
If you haven’t made your first folk tool yet, start with something small. Something you actually need. Don’t worry about whether anyone else wants it. That part tends to sort itself out. Why are you still here? Go make.


Nailed the jig drawer comparison. The shift from commercial justification to personal utility as the primary filter actually chalenges traditional ROI metrics for software development entirely. I've been building similar one-off scripts for data pipleine monitoring that no vendor would ever prioritize, and the iteration speed is wild compared to waiting for feature requests.