Stop Building God Apps: Why Small, Focused Tools Actually Win

I had a moment last week that crystallized something I've been thinking about for years. I was helping a junior developer navigate our codebase, and she asked why we had so many single-purpose internal tools instead of one unified platform. My answer took twenty minutes and revealed how little I'd actually thought about the philosophy behind it. But that's exactly what reading about local-first Mac utilities forced me to confront: the reason great software often comes in small packages, not monolithic suites.

The article I encountered wasn't about a framework or a language. It was about someone building five separate Mac applications instead of one massive productivity platform. And honestly? That thinking has been rattling around in my head ever since because it contradicts almost everything I've been taught about software scaling and user acquisition.

The Anti-Platform Movement Nobody's Talking About

Here's what struck me most: the author consciously rejected combining these tools into a single suite. ScreenShelf, PopNote, File Fetch, GeekDock, and FocusForm each solve one specific problem. You don't need all five. You install what actually hurts you, not what might eventually be useful.

This is radical in 2024. Every SaaS company I've worked with or worked at wanted to expand vertically. Add more features. Create stickiness. Make leaving expensive and complicated. But this developer went the opposite direction: lower barrier to entry, cheaper per tool, completely modular.

In Islamabad, where I work with teams building products for both local and international markets, this philosophy challenges something fundamental about how we think about product-market fit. We assume users want comprehensive solutions. Maybe they just want their problems solved without the bloat.

The Desktop as Workspace, Not Storage

The specific problems these tools address are genuinely familiar to me. My Downloads folder is a graveyard. My desktop gets cluttered. I switch between client projects and lose context constantly. I've built workarounds—shell scripts, Bash aliases, custom Finder workflows—but none of them felt like designed solutions.

ScreenShelf essentially acknowledges that your desktop shouldn't be either a dumping ground or a perfectly organized filing system. It's a working surface. Files you're actively using deserve visibility without the mess.

File Fetch solves something I particularly relate to: that moment when you know you just opened a file, but finding it again takes longer than recreating it. A menu bar app as a doorway to recent context? That's not flashy, but it's useful every single day.

Local-First Isn't Just Technical, It's Political

What genuinely impressed me was the business model. $3.99 per app, one-time purchase, no accounts, no subscriptions, fully offline. This isn't just a technical choice—it's a statement about whose computer this actually is.

I've spent enough time in discussions about telemetry, analytics, and user tracking to recognize that this approach is increasingly rare. Most modern productivity tools harvest data. Not as malice, but because that's how the business model works now. You're not the customer; you're the product.

By choosing local-first with permanent licensing, the developer isn't fighting that system theoretically. They're building an alternative that actually exists. For someone like me who's paranoid about what's running in the background on my machine, that matters.

My Take: The Clarity of Constraints

Would I have personally built these as separate apps? Honestly, I'm not sure. My instinct would be to create one unified workspace manager that handles everything. But I can already see the trap: feature creep, increased complexity, a steeper learning curve, more support burden.

There's something almost meditative about constraints that force you to ask: "What is this application really for?" ScreenShelf isn't a file manager. It's not a project tracker. It's a visual shelf for active materials. That clarity means it stays simple and solves one thing really well.

The bundled pricing ($9.99 for four apps instead of $15.96 individually) is clever too. It incentivizes exploration without forcing the full suite on anyone who just wants PopNote for quick reminders.

My question is: how many products I've worked on would be better if we'd split them into smaller, focused tools instead of merging everything? I suspect more than I'd like to admit.

What Would You Build Separately?

Think about your own workflow frustrations. Most of us respond by either abandoning the problem or subscribing to another tool. What if instead you built something specifically for that one pain point, made it work brilliantly for that single thing, and released it at a price that didn't require venture capital to make sense?

I'm curious what everyday problems developers in Pakistan are solving with custom tools—and whether any of them should become actual products.

Source: This post was inspired by "Five Local-First Mac Apps I Built to Fix Everyday Workflow Problems" by Dev.to. Read the original article