The Revolt Against Bloat: What Happens When a Builder Gets Tired of Bad Software

I got tired of switching between tabs to inspect network requests.

Not a dramatic problem. Not a startup-killing bottleneck. Just friction, the kind that accumulates quietly until one day you notice you’ve been working around something for months that should take seconds. I was doing QA and debugging, needed to capture HTTP responses, payloads, and errors in one place without hunting through DevTools panels. So I built a Chrome extension that does exactly that. Captures what I need, surfaces it cleanly, gets out of the way.

It took less time to build than the time I’d already spent tolerating the problem.

That’s a small example. But the same instinct led to bigger ones. At Decode Talent, we needed an ATS (applicant tracking software). The commercial options were either overbuilt enterprise platforms with pricing that assumed we were a Fortune 500, or lightweight tools that were missing things that actually mattered to how we hire. So we built our own. Tailored to the workflow, no licensing overhead, no features we don’t need taking up space on every screen.

I built my own internal documentation tool for the same reason. The category is full of products. None of them quite fit. So I made one that does.

And then there’s Ada, a Claude Code token optimizer we built at Jetpack Labs and named after Ada Lovelace, the 19th century mathematician widely regarded as the first computer programmer. Ada replaces Claude Code’s default tools with smarter equivalents that return exactly what the model needs, trimmed and ranked. Real-world result: 30–58% fewer input tokens on typical coding sessions. We built it because the existing tooling was wasteful in a specific, measurable way, and the fix was within reach.

None of these projects started as product ideas. They started as frustration. What made each of them possible wasn’t just the AI. It was knowing the problem well enough to define it precisely, recognizing when the output was wrong, and making the decisions the AI couldn’t make on its own.

Something Is Shifting

Last week, a developer switched to a new computer and didn’t want to reinstall Logitech Options+. So they built a replacement instead.

In Rust. With a full GUI. In under a week.

OpenLogi hit 242 stars before most people noticed it existed. It speaks HID++ directly to the hardware, stores config as plain TOML, ships both a desktop app and a headless CLI, and does it all without an account, without telemetry, and without the background processes that Logitech’s software installs on your machine whether you want them or not. The creator’s motivation, stated plainly: “No account. No cloud. No bloat.”

This is a six-day-old project built by one person. It is more technically transparent than the official product from a company that has been making mice for thirty years.

BetterMouse has been making the same argument for years from the commercial side: a solo developer, $7.99 one-time, no corporate overhead, just a clean macOS replacement for Logitech Options+. No network calls. No kernel extensions. Clean uninstall. It has been quietly thriving in the gap that Logitech created and never bothered to close.

The gap isn’t new. What’s new is how fast someone can fill it.

Why This Used to Be Harder

The moat around commercial software was never really engineering. It was time.

Writing a Rust GUI that speaks a proprietary HID protocol, implements device detection, handles per-app profiles, and ships a polished UI used to take months from a small team. Protocol docs are sparse or nonexistent. Reverse engineering takes weeks. Building the UI layer is its own project. By the time you had something functional, the commercial vendor had shipped three updates and your effort looked like a demo.

AI changes that math. Not by writing the code for you. That’s not quite how it works. But by collapsing the research phase. What used to take days of reading protocol specs and source-diving old GitHub repos now takes hours of focused conversation with a model that’s already synthesized most of what was ever written on the subject. You stay in the problem instead of spending a week finding the right abstractions to start from.

I’ve felt this directly. Building the Chrome extension for capturing HTTP responses and debugging payloads would have taken me a full weekend before. It took an afternoon. The ATS at Decode Talent, a real production system handling actual hiring workflows, is the kind of thing that would have previously required either a dedicated engineering sprint or a commercial vendor. We built it ourselves, on our timeline, shaped exactly to how we work.

The gap between “I have an idea” and “I have something running” has collapsed. What hasn’t changed is whether what’s running is actually good. That part still requires someone who knows the difference.

The Pattern Is Bigger Than Mouse Software

This isn’t about peripherals. That’s just where it’s most visible right now because the mismatch is so obvious. A settings panel shouldn’t need a cloud account.

The same dynamic is playing out everywhere commercial software got complacent:

• Documentation tools that are powerful but shaped around the vendor’s opinion of how teams should work
• ATS platforms built for enterprise recruiting workflows that don’t match how a focused team actually hires
• Debugging utilities that show you everything except the specific thing you need, in the format you need it
• AI coding tools that burn tokens wastefully because nobody optimized the default behavior

In each case, the incumbent built something good enough, then kept piling on. An account here. Telemetry there. A cloud sync you didn’t ask for. A pricing tier between you and the feature you actually need. The core functionality stopped improving. The overhead kept growing.

The people building replacements aren’t waiting for permission.

"The cost of building is approaching zero. The cost of bloat is not."

Direction Is Still the Scarce Resource

One thing worth naming clearly: OpenLogi is six days old and already architecturally coherent. It has a clean separation between the GUI app and the headless CLI. It uses GPUI, the same framework powering the Zed editor, which is a deliberate bet on a specific ecosystem, not just “a Rust GUI library I found.” Config is TOML. No binary blobs. Telemetry opt-in defaults to off.

The AI didn’t produce those decisions. The developer did.

This is the part that’s easy to miss in the “AI can build anything now” conversation. The tools compress execution time. They don’t generate direction. A model can help you implement a headless CLI in Rust. It can’t tell you whether a headless CLI matters more than the GUI for your users, or whether TOML is the right config format, or why keeping network calls opt-in-and-off-by-default is worth the tradeoff.

Every tool I’ve built (the Chrome extension, the Decode Talent ATS, Ada, the documentation tool) started with a specific complaint and a clear picture of what the solution should feel like. The AI helped me get there faster. The direction was mine.

That’s not changing. If anything it’s becoming more important. As execution gets cheaper, the differentiator shifts entirely to taste and judgment. Technical leaders who can articulate exactly what’s wrong with the existing solution and exactly what a better one looks like are the ones who will win here. They can now build it themselves, or direct a small team to build it in a fraction of the time it used to take.

There’s a flip side worth being honest about. Without that technical foundation, AI doesn’t solve the bloat problem. It reproduces it. A non-technical person pointing an AI at a problem will get something that looks like software. It may even work, for a while. But the hallucinations stack up. The security gaps don’t announce themselves. The patterns get inconsistent across the codebase. The architecture choices the AI made in session one start contradicting the ones it made in session five, and nobody notices until it breaks in production. You end up with something faster to build and just as fragile as what you were trying to replace, except now the technical debt is yours and there’s no vendor to call.

The power here is real. The prerequisite is real too. Working with someone who has the technical depth to evaluate what the AI produces, catch what it gets wrong, and hold the architecture together is what separates a tool worth building from a liability you shipped.

"AI compresses the execution. It doesn't generate the direction."

The Opportunity in the Gap

There is a category of software that exists everywhere, in enterprise tooling, developer utilities, the daily workflows of every technical team, that is quietly overdue for replacement. Not because it’s broken. Because it kept piling on.

Most of these products started as something simple. Then the business model changed. Cloud sync needed an account. Growth needed telemetry. Investors needed recurring revenue, so the one-time purchase became a subscription, and the features you already relied on moved behind a paywall. Each step made sense to someone in a boardroom. None of it made the tool better. At some point the product stopped being a tool and became a platform you’re stuck with.

Nobody defends these products on the merits. They’re sticky because switching costs existed. Those switching costs are lower now. Building the replacement is cheaper now.

If you’re a technical founder, look at the software your team installs and immediately resents. The tool everyone keeps because uninstalling it takes longer than tolerating it. The platform you’re paying for because migrating is a project you never prioritize. The debugging workflow you’ve worked around so long you stopped noticing it’s broken, like I did before I built the Chrome extension.

Then ask what it would actually take to replace it.

Six months ago, that question had a discouraging answer for most things. Today, for a surprising number of tools, the answer is: less than a week and a clear idea of what you want.

The revolt against bloat is already underway. I’ve been building my version of it for a while. What I’ve found is that the tools you build for yourself, shaped to exactly how you work and carrying none of the overhead you didn’t ask for, end up being the ones you actually use every day. But that outcome depends on having the technical depth to hold it together: to catch what the AI missed, keep the patterns consistent, and make the calls it can’t make for you.

The ones worth building are the ones you were going to complain about anyway. Find someone who understands the problem the way you do, and go build it.