Build Your Own Jigs: Why the Best Software You’ll Ever Use Is the Ugly Thing You Made for Yourself

Each time I’d discover that something had completed twenty minutes ago, I’d feel that small, familiar frustration — the kind that’s easy to dismiss in the moment but accumulates like sawdust on a workshop floor. You sweep it aside, you keep working, you tell yourself it’s not that bad.

On Tuesday, I stopped tolerating it.

I built a Mac desktop app. Small, persistent, sits above my other windows. Shows me the real-time status of every Claude Code session. I can click on any one of them and bring that instance to the front. It took an afternoon. It’s not pretty. It’s definitely not something I’d put in the App Store. A friend of mine has built a far more polished version of the same general idea.

But here’s the thing: mine works exactly the way I need it to, for my specific setup, solving my specific problem. And the moment I started using it, something unexpected happened. Ideas started showing up. A dozen of them, at least. What else could I automate? What other small, personal tools could I build that serve nobody but me?

The Tipping Point

There’s a moment — and I’ve been asking friends about this because I’m genuinely curious about the science behind it — where you stop accepting a broken workflow and decide to do something about it. BJ Fogg at Stanford has a behavior model that explains part of it: behavior happens when motivation, ability, and a prompt converge at the same time. The interesting piece is that lowering the friction of taking action is often more powerful than increasing your motivation to act.

That’s what AI tools have done for personal software. The friction of building something just for yourself has dropped to almost nothing. Five years ago, my monitoring app would have been a weekend project requiring frameworks and dependencies and debugging I didn’t want to deal with. Today it was an afternoon conversation with an AI that understood what I needed.

Ed O’Brien at the University of Chicago has studied tipping points specifically and found something that matches my experience exactly: people are more sensitive to negative accumulation than positive change. We notice frustration stacking up faster than we notice things getting better. So we tolerate a broken workflow for weeks, then suddenly fix it in hours and wonder why we waited.

I think the reason we wait is that we’ve been trained to think building software means building a product. And building a product means worrying about users, scalability, design systems, app stores, marketing, support. That’s an enormous amount of overhead for someone who just wants to see which of their AI sessions has finished running.

FORGE is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

The Jig on the Shelf

If you’ve spent any time around a woodworker’s shop, you’ve noticed the jigs. They’re everywhere — clamped to benches, hanging on walls, stacked on shelves. A jig is a custom-built fixture that makes a specific operation repeatable and controllable. Need to cut a consistent arc on chair backs? Build a jig. Need to drill holes at the same angle every time? Build a jig. Need to hold an odd-shaped piece steady while you work on it? Build a jig.

Here’s the thing about jigs: you won’t find most of them in any catalog. The majority are user-made, as occasion demands. They’re built for one shop, one craftsperson, one recurring task. In the Japanese woodworking tradition, as Toshio Odate documents in Japanese Woodworking Tools, toolmaking isn’t separate from the craft — it is the craft. Modifying, tuning, and caring for your tools is part of mastery, not a distraction from it.

My Mac desktop app is a jig. It sits on my digital shelf. I pull it out every morning when I start working. It does one thing, for one person, in one specific context. And that’s exactly what makes it useful.

The software industry has spent decades optimizing for scale. Build once, distribute to millions. That’s a valid model — it’s how most of the tools we use got built. But it’s created a blind spot. We’ve internalized the idea that if software isn’t built for everyone, it’s not worth building. That’s like saying a woodworker shouldn’t build a jig because Home Depot doesn’t stock it.

Home-Cooked Software

I’m not the only person thinking about this.

In 2020, Robin Sloan wrote an essay called “An App Can Be a Home-Cooked Meal” that reframed the entire conversation. He’d built a messaging app used by exactly four people — his family. His argument was simple: people don’t learn to cook to become chefs. They cook to feed people they love, out of curiosity, to carry on traditions. Coding can connect to the same human impulses.

Five years later, Sloan revisited the idea and noted that AI tools — he names Claude specifically — are “like super-duper food processors for the home-cook programmer.” The barrier that kept most people from building personal software has largely collapsed. You don’t need to know how to write Swift to build a Mac app anymore. You need to know what you want the app to do.

Maggie Appleton expanded on this with her concept of “barefoot developers” — technically savvy people who want agency over their tools but don’t want to become full-time programmers. Teachers building custom grading dashboards because the school’s LMS can’t sort the way they think. Students wiring together notification scripts for scholarship deadlines. People like me, building monitoring apps for a specific AI workflow. She argues we’re on the verge of a golden age of local, home-cooked software.

Allen Hutchison gave it the cleanest definition I’ve seen: “software written for an audience of one” — an application built to solve a specific problem for a specific person, with no intention of scaling, monetizing, or sharing. He built a GitHub notification filter in twenty minutes. Not a product. A jig.

Why This Feels Different

There’s a reason building personal tools feels fundamentally different from using someone else’s software, and Ryan and Deci’s research on self-determination explains it clearly. Intrinsic motivation — the kind that sustains you — is fueled by three things: autonomy, competence, and relatedness. Building your own tool satisfies all three at once. You choose what to build. You solve a real problem. And you often build it for yourself or people you know.

Compare that to adopting a new SaaS product. Someone else chose what to build. The competence you develop is in navigating their interface, not solving your problem. And the relatedness is between you and a company’s support docs.

This isn’t an argument against commercial software. I use commercial tools constantly and I’m glad they exist. It’s an argument for recognizing that there’s a category of problem — small, personal, specific to your workflow — that commercial software will never solve well, because the market for an audience of one doesn’t attract venture capital.

Professor Beekums wrote a post called “Not Everything Needs to Scale” that captures this perfectly. He built a medication reminder using Twilio that calls one person three times a day. Making it scalable would have taken ten times longer. And the version that works for exactly one person is not only sufficient — it’s the best version. No edge cases from other users. No feature requests. No compromise.

The Trap of Turning Everything Into a Product

I want to stay on this point for a moment, because I think it’s the thing that stops most people from building their first jig.

We’ve absorbed a cultural reflex — especially those of us who build things professionally — that every project should be evaluated for its potential as a product. Could this be a startup? Could I sell this? Should I put it on GitHub? Should I write a blog post about it and build an audience? The moment you start asking those questions, you’ve added a thousand pounds of weight to something that should be light. You’re no longer building a jig. You’re building a business plan.

Adam Derewecki makes the case directly: do things that don’t scale, and then don’t scale them. That’s the whole strategy. Not as a stepping stone to scaling later. As the actual, complete, finished approach.

My monitoring app doesn’t have error handling for edge cases that will never happen on my machine. It doesn’t have a README because no one else is going to run it. And that’s not laziness — it’s clarity. I know exactly who this tool is for and what it needs to do. Every feature I don’t build is time I spend doing actual work.

The moment you give yourself permission to build something that will never be a product, the scope collapses to something you can actually finish. And finishing is the whole point. A jig on the shelf beats a product in your head.

The Adjacent Possible

Here’s where I want you to pay attention if you’ve been nodding along but haven’t built anything yet.

After I launched my monitoring app — this small, ugly, personal thing — something happened that I didn’t expect. Ideas started cascading. What if I built a tool that tracked which projects I’d made progress on this week? What about a Raspberry Pi with a touch screen in my office showing a heads-up display of active work? What other weird, buggy software tools could I have running on my machine that I never have to worry about selling to anyone?

Steven Johnson, drawing on Stuart Kauffman's work in complexity theory, calls this the “adjacent possible” — a concept borrowed from complexity theory. At any given moment, only certain next steps are available to you. But each step you take opens new doors that weren’t visible before. Building one jig reveals the need for the next one. The first personal tool you build isn’t the destination. It’s the key that unlocks a hallway of doors you didn’t know existed.

And the experience of building it puts you into what Csikszentmihalyi called flow — that state of complete absorption where the activity becomes its own reward. The feedback loop is immediate (it works or it doesn’t), the challenge scales with your skill, and the goal is concrete. Flow states are self-reinforcing. You finish one thing and you want to start the next.

This is the cascade effect. One tool leads to two ideas. Two ideas lead to five. Before you know it, you’re not just someone who uses tools — you’re someone who makes them. And that’s a fundamentally different relationship with your work.

What to Build First

The question I keep coming back to is this: Is there a tool I can make that gives me a great deal of efficiency and keeps me engaged in doing the work and excited about it?

That dual filter matters. Efficiency alone leads you toward automating things you don’t care about — useful, but not energizing. Engagement alone leads you toward interesting projects that don’t actually help your workflow. The sweet spot is the tool that saves you real time AND that you’re genuinely curious to build.

Here’s a practical way to find it:

Start with your frustrations. What do you tolerate every day that you’ve stopped noticing? The thing you work around. The information you check manually. The process that requires three clicks when it should require zero. That’s your first jig. You don’t need to be a developer to notice these — a teacher who copies the same data between two systems every morning has found a jig worth building.

Keep it absurdly small. Allen Hutchison built his GitHub notification filter in twenty minutes. My monitoring app was an afternoon. The point isn’t to build something impressive. The point is to build something that works for you, today, without worrying about tomorrow.

Give yourself permission to build something ugly. No landing page. No logo. No README. No tests. No one is going to review this code. No one needs to understand it but you. Robin Sloan’s family messaging app doesn’t need a design system. Your workflow tool doesn’t need one either.

Don’t scale it. This is the hardest part for people who build things professionally. The instinct to generalize, to abstract, to make it work for “anyone” — resist it. If a jig becomes genuinely useful to your team someday, you can deal with that then. But the fastest way to kill a personal tool is to design it for people who don’t exist yet.

The Jig Is the Point

We’re living through a moment where the tools to build personal software are better than they’ve ever been. The local-first movement is providing the philosophical foundation — you own your data, you own your tools, you don’t depend on someone else’s business model. AI is providing the practical foundation — you can describe what you need and get a working version in an afternoon.

But the opportunity isn’t about AI. It’s about reclaiming agency over your own workflow.

Every craftsperson who’s ever built a jig knows this feeling. You have a problem. You have materials. You have the skill — or enough of it — to make something that works. And the thing you make is imperfect and specific and exactly right for you. It goes on the shelf. You pull it out when you need it. And the next time you face a new problem, you think: I could build a jig for that.

That’s the tipping point I keep thinking about. Not the moment when AI gets good enough. The moment when you decide that the friction you’ve been tolerating is a problem you can solve. The moment you stop being a consumer of tools and start being a maker of them.

The first one is the hardest. After that, it’s just jigs all the way down.