How Small Problems Become Big Software Products

The Tool That Just Works

I open Sublime Text dozens of times a day. When I need to tweak a config file, edit a script, jot down a quick snippet, or inspect a log, it’s the first thing I reach for. I don’t think about it—I just press a keyboard shortcut and the window is there, ready for typing before my fingers have settled on the keys. There’s no splash screen, no project loading, no indexing spinner in the corner. I type, the characters appear, and I move on with my life.

That speed is the entire product. Sublime Text isn’t a full development environment. It doesn’t manage my database connections, run my test suite, or offer built-in refactoring tools. It doesn’t try to be Visual Studio Code or IntelliJ. And that’s exactly why I keep using it. The problem it solves is small: I need to open a file and edit it quickly. It solves that problem so well that I’ve never once wished it did more.

The same pattern shows up in the other tools I use daily. My terminal gives me direct control over the machine—no GUI abstractions, no wizards, just a prompt and an immediate response. Chrome is where I do most of my online work because it renders pages fast and stays out of the way. The file manager on my system handles moving, renaming, and organizing files without ceremony. Kodi plays my media collection without demanding I sign up for an account or subscribe to a service. Each of these tools has a narrow job, and each does that job with enough reliability that I stop thinking about the tool itself and just use it.

From Small Irritations to Household Names

There’s a quiet lesson in this: software that becomes indispensable often starts as a fix for a small, recurring annoyance. Not a grand vision. Not a platform play. Just a person or a small team who got tired of doing something manually and built a tool to make it easier. Then other people with the same annoyance found the tool, and it grew.

Instagram began as a way to make phone photos look decent with filters. That was it. The founders weren’t building a global social network—they were solving the problem of ugly mobile photos. Airbnb started because two guys needed to pay rent and put an air mattress on their floor. GitHub started as a place to host code and collaborate on open source. Stripe started because accepting payments online was absurdly complicated for developers. Notion started as an internal wiki for a small team. Slack started as the internal chat tool for a game company. Trello was a board for tracking tasks inside Fog Creek Software.

None of these started with a mission to change the world. They started with a specific problem, a focused solution, and a group of users who felt the same pain. The scale came later, after the core usefulness was already proven.

Why Small Problems Are the Right Starting Point

There’s a practical reason for this. When you solve a small problem, you can understand it completely. You know exactly what the user is trying to do, where it breaks, and what “better” looks like. You can build a tool that fits that problem like a glove, without the bloat of features that half-serve a dozen different use cases. And when someone else encounters that same problem—which they will, because the world is full of people doing similar work—they’ll recognize your solution immediately. No marketing required. They’ll just see it and think, “That’s exactly what I needed.”

Trying to build a platform from day one is a different game. A platform has to serve many different users with many different needs, which means you can’t go deep on any single one. You end up with a surface-level solution that’s okay at everything but great at nothing. Users don’t stick around for “okay.” They stick around for the tool that makes one part of their day disappear.

Sublime Text is my proof of this. It doesn’t do everything, but the one thing it does—fast, reliable text editing—it does so well that I’ve never seriously considered switching. The developer could have spent years adding project management, integrated debugging, and a plugin marketplace (well, it does have a plugin marketplace, but that came later, after the core was solid). Instead, they focused on the core. And the core is why people still use it.

Focus Is a Feature

This is a hard lesson for builders because it runs against the instinct to add more. When you’re building something, every new feature feels like progress. Every integration feels like value. But every addition also dilutes the focus that made the product useful in the first place. A tool that tries to solve five problems usually solves all five poorly. A tool that solves one problem perfectly earns a permanent place in someone’s workflow.

I’ve learned this the hard way with my own video editor projects. My first editor was built around transcripts—a clever idea that worked well for a specific kind of video but couldn’t stretch beyond it. My second editor was built in C++ with grand ambitions of being a full non-linear editor, and it collapsed under the weight of its own infrastructure before I ever got to the features that mattered. The lesson from both: pick a small, clear problem and solve it deeply. Don’t try to be everything.

TrailStudio, my current project, is an attempt to apply that lesson. The core problem is editing a video timeline—dragging clips, trimming them, arranging them on multiple tracks. It’s a problem I encounter every time I edit a video, and it’s a problem that has annoyed me in every existing editor I’ve used. The temptation to add cloud collaboration, asset management, and a hundred other features is real. But the right move is to make the timeline itself so fast, so smooth, so reliable that people forget they’re using software at all. That’s the Sublime Text model: do one thing, do it instantly, and let the user get on with their work.

The Next Big Product Is Probably a Small Annoyance

I think about this every time I catch myself grumbling at my computer. The ten seconds I spend waiting for a bloated application to load. The three clicks it takes to do something that should take one. The tiny workaround I’ve memorized because a tool doesn’t do what I expect. Each of those is a small problem. And each of those small problems is an opportunity for someone to build a tool that eliminates it.

The software products that become part of our daily lives rarely start with a pitch deck and a vision statement. They start with a person who was annoyed enough to build a fix. Then another person used it, and another, and the small problem turned out to be a shared one. The scale was a byproduct of the usefulness, not the goal.

So if you’re trying to decide what to build, don’t look for the big idea. Look for the small annoyance you’ve learned to live with. The one you’ve stopped noticing because you’ve been working around it for so long. That’s probably where the next Sublime Text, the next Instagram, the next Stripe is hiding. Not in a grand vision, but in a daily irritation that someone finally decided to fix.