Build Your Own Tools - No One Else Will

TL;DR: When work ties your hands, building your own tools, both in the office and the garage, can be the key to moving faster, reclaiming agency, and actually enjoying the process again.

The Work Dilemma

In enterprise software, the pressure is always the same: deliver more, deliver faster. But at the same time, the systems you rely on are off-limits. You’re not allowed to poke around in the guts, even if those guts are on fire. Priorities are set by the product team, and internal tooling always comes last, if it’s ever considered at all.

Tech debt? We’ll talk about that later, but later never comes. The opportunity cost of fixing what’s broken is always weighed against shipping new features. “We can’t spend two sprints refactoring when we could be building the new analytics dashboard!” Never mind that the current dashboard is held together with duct tape and prayers. The pressure to never look back, to never clean up what you’ve built, turns your codebase into a game of Jenga that nobody wants to touch.

You’re expected to run a race, but you’re not allowed to lace your own shoes. Or check if they’re on the right feet. Or if you’re even wearing shoes.

The Epiphany: Build Your Own Tools

The epiphany didn’t come from writing code, it came from woodworking.

In the shop, it’s completely normal to spend hours building templates or jigs before making a single real cut. A botched cut on a $300 slab can blow the whole project (and your weekend). So you invest in the things that reduce risk and make future work easier, even if that means stopping to build the tools first.

That same mindset clicked for me at work. If I’m tripping over the same problem more than once, that’s a sign: build the tool. Make the jig. Automate the annoying part. Future You will say thanks. Present You will at least grumble less.

This is the essence of Jidoka, one of the core ideas behind the Toyota Production System. Jidoka means “automation with a human touch,” the idea that when a problem occurs, the system should stop so it can be fixed at the source. In practice, it means designing your environment so that issues are surfaced early and clearly, and tooling exists to deal with them fast. Whether you’re assembling a car or pushing code, the principle is the same: build quality in, don’t patch it later.

It’s not rebellion, it’s just how you get things done when the system around you won’t help.

DeskThang: A Case Study

I’ve been working on a little project called DeskThang, a physical device that lives on your desk and quietly tells you what you care about.

• CI pipeline failed? Red flashing
• Stripe sale? Purple pulse
• Cursor’s agent mode is waiting for you? Blue glow
• Want something else? Fully scriptable from bash:

  deskthang led 00ff00    # Set LED to green
  deskthang image test.png # Display an image
  

It’s scriptable, open-source, works over USB, and doesn’t spy on you. Designed for people like me, devs who want ambient context without Slack pings, browser tabs, or pulling out a phone to get sucked into the void. (deskthang.com)

I started with a 3D-printed enclosure, which works well to show off the concept. But I want more. I want something beautiful, a device I’ll be proud to leave on my desk. Something with wood, weight, and actual presence.

So I set out to build a wooden version.

That meant learning how to kerf-bend 1/8" Baltic birch plywood. Mine is made up of three layers. The trick is to cut just deep enough, through about 1.75 layers, so the outer veneer stays intact and bends without snapping. We’re talking about a margin of error of 0.2mm-cut 1.8mm when you need 1.6mm and it snaps. Go too shallow at 1.4mm and it won’t bend at all. Every cut has to be that precise, dozens of times across the piece.

Then comes the steaming. You’ve got to soften the wood before shaping it into curves. Only after it cools and dries do you get to see if your spacing and depth were consistent enough to hold a clean bend.

It’s taken a lot of trial and error, but each iteration got better as I improved my process. Without the sleds, the jigs, the templates, and without CAD and Blender for modeling and fit checks, it wouldn’t be possible. It’s the same mindset as building software tools: remove the friction, one annoying detail at a time.

Same lesson: when the process sucks, pause and build the thing that makes it suck less.

Bonus: now I get to pretend I’m an old-world craftsman and ship functional hardware.

Next post: we’ll get into epoxy resin art and building custom light pipes for the wooden version. I’ve got some glow experiments queued up.

Why This Matters

At work, no one’s going to hand you the time or space to fix broken workflows. But you can sneak efficiency in through the side door. A script here. A CLI tool there. A bit of automation no one asked for, but everyone mysteriously starts using.

At home, you can go even further. You can build for joy. You can experiment. You can turn a bad cut into a better jig.

Tools aren’t just about speed, they’re about predictability. Predictable means repeatable, repeatable means reliable, and reliable means fast.

Every tool you build removes guesswork, smooths friction, and transforms uncertainty into clarity. And clarity is always quicker.

Closing Thought

If something keeps slowing you down, stop. Step back. Ask yourself: could I build something that fixes this?

Whether you’re coding, crafting, cooking, or managing a team, the principle stays the same: when friction slows you down, build the tool that speeds you up. The solution might be a script, a jig, a checklist, or a new process-but the mindset of building your own tools applies everywhere.

More often than not, the answer is yes, and no one else is going to do it for you.