Why We Need Small, Focused Software Tools Again

There was a time when software did one thing and that was the entire deal, it opened files, played music, calculated numbers, printed labels, or shut up when you told it to, and once you installed it, it stayed put, it didn’t ask questions later.. it didn’t grow ambitions, and it didn’t slowly change the terms of the relationship while you weren’t looking, and somewhere along the way that idea became unfashionable, even suspicious.

Today even the simplest utility arrives wrapped in onboarding screens, analytics frameworks, cloud dependencies, subscription prompts, remote configuration flags, feature experiments, and a permanent background connection to someone else’s servers, and none of that happened because users asked for it, it happened because someone else needed leverage, because software stopped being about solving problems and started being about maintaining optionality after install.

Modern software bloat isn’t an accident and it isn’t sloppy engineering, it’s intentional architecture, every extra permission request, every dependency, every opaque update exists because it serves a business goal, tools that once worked entirely offline are now designed to be porous by default, quietly collecting data, optimizing engagement, and justifying their continued presence in your life, even though a mute button doesn’t need a backend, a barcode scanner doesn’t need an account, and a shipping calculator doesn’t need telemetry, yet here we are.

When a business model depends on ongoing extraction, software can’t be allowed to settle, features accrete not because they improve reliability but because they create motion, interfaces become denser, settings multiply, and updates arrive that don’t fix bugs so much as adjust terms, permissions, or behavior, and over time the tool you installed slowly stops belonging to you, even though nothing explicitly broke.

Free software isn’t free, payment still happens, it’s just deferred and hidden, instead of money you pay with attention, metadata, behavioral fingerprints, long-term lock-in, and a gradual erosion of control, and once incentives are misaligned the outcome is predictable, if profit depends on engagement the software will resist efficiency, if revenue depends on retention the software will resist closure, and if ads are involved clarity becomes the enemy, none of which is conspiracy, it’s just arithmetic.

Subscriptions didn’t take over because they’re better for users, they took over because they stabilize cash flow, and stable revenue tends to produce unstable software, features are added not because they’re necessary but because churn must be justified, simple tools inflate into platforms, interfaces degrade, and cancellation becomes harder slowly enough that most people tolerate it, and we’ve all watched a perfectly reasonable one-time purchase quietly transform into a lifetime obligation.

Small, focused tools are dangerous, but only to the wrong people, because once a tool works it stops evolving, once it’s correct it stops changing, and once it’s predictable it stops generating engagement metrics, which is a problem only if your business depends on perpetual motion rather than usefulness.

Local-first software introduces an uncomfortable reality that a lot of modern systems quietly avoid, because when software runs entirely on your device there’s nothing to sell, nothing to track, nothing to mine, and nothing to optimize remotely, no dashboard lights up when you open it, no metrics team debates your behavior, and entire revenue strategies collapse simply because the software refuses to participate, which is why local-first gets framed as old-fashioned and cloud dependency gets sold as convenience even when it introduces fragility, latency, and failure modes.

At M Media Software Lab we build with deliberate constraints, one job per tool, no accounts unless unavoidable, no ads, no trackers, no dark patterns, no artificial friction, if the operating system allows something to be done locally it stays local, and if a feature doesn’t improve reliability it doesn’t ship, not because we’re nostalgic but because this is what risk management looks like when you’ve been around long enough to see how these systems fail.

Yes this approach limits scale, yes it reduces recurring revenue, and yes growth is slower, but that tradeoff is intentional, we’re not trying to extract value indefinitely, we’re trying to finish the job, ship the tool, and respect the boundary between software and the person using it.

Software should be boring again, the most trustworthy tools don’t surprise you, they don’t experiment on you, they don’t change behavior overnight, they sit quietly until needed and then they work, and that’s the kind of software we build, because it’s the kind we actually want on our own machines.