Why I'm Building One Tool A Week and What I'm Learning

The New Year

Around the turn of the new year, I read this article from Scott Belsky and I couldn’t stop thinking about this prediction:

We’ll see the rise of “internal development teams,” as companies replace single-purpose bloated SaaS products with their own apps that collapse functions in magical ways. New internal application development teams will be spawned in large companies, and they’ll “vibe code” tailor made software and agent-driven solutions for functions around the company. At first, these efforts will replace SaaS products (especially those that are expensive private-equity-owned clunky solutions). Over time, these home grown tools will start to collapse functions into one another.

I probably reread this portion of the article more than five times, going back to it and feeling a burst of excitement each time. At the time I couldn’t articulate why the prediction left such an impression on me. But now, a few weeks later and with two tools (Clara and Megaphone) already built, I think I can explain it.

The Problem Nobody Talks About

Every company I’ve worked at pays a lot of money for inefficiency. And everybody just goes along with it.

The $50K/year tool that does one thing. The process that takes 30 minutes but should take 30 seconds. The workaround that became permanent. The thing everyone complains about in Slack but nobody fixes.

It’s not that companies lack engineers. It’s that no one owns the small stuff. The big systems get attention, budgets, and roadmaps. The small, high-leverage tools that would actually make work easier? They sit on a backlog forever or get solved with another expensive vendor.

Why Small Tools Matter

When I built Clara, I did the math. The tool I built in a few days would cost 93% less than the existing solution. Not because I’m cheaper than a vendor. Because the problem didn’t need a vendor in the first place.

That’s the cost arbitrage nobody talks about. Companies pay $50K,$ 100K, sometimes more for tools that solve problems a single builder could fix in a week. Not because the vendor is better, but because nobody internally is dedicated to solving it.

The ROI on small tools is often higher than enterprise software. A tool that saves 10 people 30 minutes a week pays for itself in days, not years.

But nobody builds these tools because:

It’s nobody’s job. There’s no “Head of Small Tools” role. So small problems stay unsolved.
Leadership doesn’t see the ROI until someone shows them. The savings are invisible until you do the math out loud.
People don’t realize they can build these things now. AI changed the game. You don’t need to be an engineer anymore to ship real software.

That last one is the big one. The leverage is there. Most people just haven’t picked it up yet.

The Experiment

I’m building one internal tool every week for a year. 52 tools. 52 weeks. Not because I have to, but to prove a point: most business problems don’t need a vendor, a 6-month roadmap, or a $50K budget. They need someone who listens, builds fast, and iterates.

Each tool follows these rules:

Must solve a real problem I’ve observed
Must be built in one week
Must be demo-able by the end of the week

What’s Already Happened

Week 1, I built Clara, an AI-powered time-off request system. It got traction internally and sparked real conversations about how we build tools.

Week 2, I was in a cross-functional meeting in the morning. I heard colleagues talking about how hard it was to publish product announcements without engineering help. By that evening, I had Megaphone working. A self-service publishing platform where PMs can create “What’s New” content, target it to specific product instances using customizable tags, set auto-expiration dates, and get AI assistance for writing. It also has an API constructor so engineers can grab the content however they need it. 7 hours from problem to working app.

That’s when it clicked. This isn’t just a side project. This is a career.

What I’m Learning

A few weeks in, here’s what’s already clear:

Speed beats perfection. A tool that works today beats a perfect tool next quarter. I showed Megaphone to leadership less than 24 hours after I heard the problem. That velocity matters more than polish.

Listen for pain. Every meeting has someone saying “I wish we had…” or “this process is so manual.” Those are tool ideas. I just started writing them down.

Small tools face less resistance. Clara was ambitious and hit some organizational friction. Megaphone was smaller, faster, and got interest almost immediately. Start small, build trust, go bigger.

AI changes the math. I’m a UX designer. Six months ago I couldn’t build a full-stack app. Now I can ship one in a day. The leverage AI provides is real, and most people haven’t caught on yet.

The Bigger Picture

This isn’t really about tools. It’s about a different way of working. One where we stop accepting broken processes and start fixing them. Where we measure impact in time saved, not features shipped.

As a designer, I’ve always been trained to listen for problems and craft solutions that fit how people actually work. The difference now is that AI collapsed the gap between ideation and shipping. I don’t just design the solution anymore. I build it too.

52 tools from now, I’ll have a body of work that speaks for itself. And hopefully, a seat at the table to keep building.

Say hello if you want to talk.