THE 'BLOATWARE' DISEASE IN SOFTWARE AND THE RISE OF SINGLE-PURPOSE MICRO-TOOLS
THE 'BLOATWARE' DISEASE IN SOFTWARE AND THE RISE OF SINGLE-PURPOSE MICRO-TOOLS
Instead of dashboards that promise all-in-one solutions and drown your team in 50 different features, why will tools that do one job flawlessly win?
The Problem: 50 Features, 4 in Use
When we looked at the usage logs of an "all-in-one" operations dashboard that one team pays an annual license for, the picture wasn't surprising: the menu had more than 50 modules, and four of them had been opened in the last 90 days. Watching a value on a page, making a PDF safe to share, turning a meeting recording into text and dropping an alert into Slack. The other 46 modules only crowded the menu and brought a new settings screen with every update.
The symptoms of bloatware are the same everywhere:
- Menu hunting instead of searching: To do a simple job you first have to find the right module.
- Every update is a risk: A feature you don't use changes and breaks the one you do.
- Training cost: A half-day "let's get to know the dashboard" session for every new teammate.
Why Does Everything Bloat?
Bloat isn't a design mistake; it's the outcome of a business model. When software is sold per seat and tier by tier, the way to sell the next tier is to add features. Enterprise procurement feeds this too: if the tender spreadsheet has 80 rows, the product that ticks all 80 boxes wins. Nobody asks how many of those 80 features will actually be used.
“Adding a feature takes a sprint. Removing it never happens, because nobody can be sure that nobody uses it.”
The result: every customer searches for their own small need inside a giant interface that is the sum of everyone's needs.
The Micro-Tool: One Input, One Output, One Job
Every tool at Incapon starts as one sentence on the request board and stays within the bounds of that sentence. Detector watches a single value on a page and tells you when it changes; it doesn't archive the whole page or produce an SEO report. The PDF Editor's redaction pass deletes the text under the area you mark from the file. Signature verification compares a signature with the same person's past signatures and gives it a score. Subtitles transcribes a recording once and translates it into the languages you want.
Our test for whether something is a micro-tool is simple:
- One sentence: Can you say what the tool does in a single sentence without leaning on the word "and"?
- One screen: Can it be set up and used on one screen, without a separate settings page?
- Measurable cost: Can we say how many cents a single run costs?
If we can't answer yes to all three, what we have isn't a tool but the draft of a platform, and we split it.
The Engineering Benefit of Being Small
A single-purpose tool has a small codebase, and small code is cheap to maintain. Detector's core is a loop a few dozen lines long: download the page, find the selector, compare the value, notify if it changed. When it breaks, it's obvious where. That's also why we can offer bug fixes free for life; a 50-module platform couldn't make that promise.
Cost shrinks by the same logic. A tool watching a single value costs about $0.12 a month, because it doesn't spin up a full browser and doesn't download anything it doesn't need. All-in-one platforms, on the other hand, have to run the infrastructure for modules you don't use every month, and the bill for that infrastructure lands on you.
Then there's composability. Small tools connect to each other through webhooks: Detector's alert lands in Slack, Subtitles' output lands in a folder. Instead of a big platform's "integrations module", you build your own flow from parts that each do one job.
Where Micro-Tools Stop
We're not claiming everything can be solved with micro-tools. An accounting package or an ERP needs tightly linked data to stay consistent in one place; splitting it into ten pieces breaks that consistency. Our territory is the small, repetitive jobs at the edges of those big systems, the ones nobody thinks are worth writing a module for. Jobs that eat two hours of a team's week but never make it onto any product roadmap.
Try a one-minute experiment with your team: count the screens you actually opened last month in the software you pay the most for. If the number is small, one of those screens may be waiting to become a single sentence on the request board.
NEXT POSTS
How does a 23-model AI consensus detect forged signatures?
Why does a silently broken page return HTTP 200? The silent failure detector
From our request board to production: how do community requests become products?
Got a Process Like This Too?
Tell us about the tedious manual task that costs your team at least 30 minutes every day; we will design a working in-browser micro tool for it in 48 hours.