How Solo Developers Decide What Not To Build

The hardest part of building software alone isn’t writing code. It’s deciding what not to write. Every solo developer has a running list of ideas—features that would be cool, integrations that would be useful, optimizations that would make things faster, refactors that would make the code cleaner. The list grows faster than anything gets built. And unlike a team, there’s no one to delegate to, no one to push back with a different opinion, no one to share the burden of choosing. Every decision lands on the same set of shoulders.

I’ve been there. I’ve built enough projects now to know that the ideas are never the problem. The problem is the willingness to let most of them go. When I started TrailStudio, I had a long list of features I thought a video editor needed. Some of them came from my previous attempts. Some came from watching how other editors worked. Some came from imagining what users might want someday. But if I’d tried to build even half of that list, TrailStudio would have collapsed under its own weight before it ever shipped. The discipline wasn’t in coming up with ideas. It was in refusing to build most of them.

The Cost of Saying Yes

Every feature has a cost. That sounds obvious, but solo developers often underestimate what the cost actually is. It’s not just the time to build the feature. It’s the time to maintain it, to document it, to test it when other things change, to debug it when it breaks, to rewrite it when the architecture shifts. A feature that takes a week to build takes months to keep alive over the course of a product’s life. And that’s if the feature turns out well. If it turns out poorly—if it’s rarely used, if it confuses people, if it conflicts with other features—then it’s a permanent drag, a thing you can’t remove because someone might be using it, but can’t improve because you don’t have the time.

The deeper cost is opportunity cost. Every hour spent building a feature that doesn’t matter is an hour not spent building the thing that does. For a solo developer, time is the scarcest resource. There’s no one to parallelize with, no one to hand off to. The clock is always running. A feature that takes a month to build is a month you’ll never get back. If that feature doesn’t pull its weight, you’ve effectively burned a month of your working life on something that didn’t move the product forward.

This is why the most important skill for a solo developer isn’t technical. It’s the ability to look at a list of possibilities and cross out most of them without hesitation. The feature that gets cut doesn’t send an angry email. It doesn’t stage a protest. It just quietly disappears, and the product is better for its absence.

Learning What Not to Build by Building the Wrong Things

The transcript-based editor I built before TrailStudio taught me this lesson the hard way. The idea was elegant: edit video by editing text. Delete a sentence, and the corresponding clip disappears. Drag a paragraph, and the scene moves with it. For a specific kind of video—a talking-head explainer, a podcast recording, a lecture capture—this was genuinely useful. The problem was that the entire architecture was built around that one workflow. When someone wanted to add b-roll, or a music track, or a title overlay, the transcript stopped being the center of the project. The product didn’t have a second gear.

I could have kept adding features to that editor. I could have built a separate timeline mode for non-transcript content, or a hybrid view that showed both the text and the clips. I could have kept iterating, adding complexity, trying to make the transcript-based approach work for everything. But that would have been saying yes to a fundamental mismatch between the architecture and the problem. The better decision was to stop, recognize that the transcript model was too narrow, and start over with a different foundation.

The C++ editor taught me the opposite lesson. It was built to be flexible—a proper non-linear editor with multiple tracks, keyframes, and the ability to handle any kind of content. But the flexibility came at a brutal cost. Every component had to be built from scratch. Every feature required threading through layers of low-level infrastructure. I spent weeks building panels that should have taken hours. The architecture was so heavy that I couldn’t move fast enough to learn anything. The lesson there wasn’t about what features to avoid. It was about what architecture to avoid—the one that makes every yes expensive and every no feel like a relief.

TrailStudio exists because those two projects taught me what not to build. Not in an abstract sense, but in a concrete, felt sense. I know what it’s like to build a feature that the product doesn’t need. I know what it’s like to build an architecture that can’t support the features the product does need. Those lessons were expensive, but they were also clarifying. Every time I’m tempted to add something new to TrailStudio, I check it against those experiences. Does this feature serve the core workflow, or does it distract from it? Does this architecture choice make it easier to iterate, or harder? The answer is usually no to the first and yes to the second.

The MVP Is a Filter, Not a Floor

The concept of a minimum viable product gets thrown around a lot, but most people misunderstand it. An MVP isn’t the smallest version of your product that you can ship. It’s the smallest version that lets you learn what you need to learn. The distinction matters. If you’re building an MVP to learn whether users want a particular workflow, you don’t need polished settings panels or account management or a plugin system. You need the workflow, working well enough for someone to try it and tell you whether it’s useful.

That’s the filter. Every feature should be tested against a single question: what will I learn by building this? If the answer is “not much,” the feature doesn’t belong in the MVP. Maybe it belongs in the backlog. Maybe it belongs in the trash. But it doesn’t belong in the thing you’re building right now.

The MVP is also a floor, not a ceiling. It’s the minimum, but the minimum still has to be good. A timeline that stutters is not an MVP—it’s a broken promise. A transcript editor that can’t handle b-roll is not an MVP—it’s a dead end. The discipline is to build something small enough to ship quickly but good enough that users can actually evaluate it. That’s a narrow window, and hitting it requires saying no to almost everything.

For solo developers, the MVP is especially important because it’s the only thing standing between you and the infinite feature list. Without it, you’ll keep adding things, telling yourself that the product isn’t ready yet, that it needs just one more feature before anyone can use it. The MVP gives you permission to stop. To say: this is enough to learn from. Ship it, see what happens, and let reality shape what comes next.

The Questions That Guide the No

So how does a solo developer actually decide what not to build? There’s no formula, but there are questions that help. The first is simple: does this serve the core use case? Every product has a reason to exist, a problem it solves that nothing else solves quite as well. For TrailStudio, that problem is editing a video timeline—dragging clips, trimming them, arranging them on tracks. Every feature either serves that core or doesn’t. A cloud collaboration tool doesn’t. A built-in stock footage library doesn’t. A sophisticated color grading suite doesn’t, at least not yet. They might be useful someday, but they’re not the reason someone chooses the product.

The second question is: can I maintain this alone? A feature that requires constant attention—a server component that needs monitoring, an integration that breaks when a third-party API changes, a codebase module so complex that it needs its own documentation—is a liability for a solo developer. The feature might be valuable, but if it can’t survive without ongoing care, and the solo developer is already stretched thin, it’s not sustainable. Better to build something simpler that works reliably than something ambitious that rots.

The third question is: will this be used by the people who actually use my product, or by the people I hope will use it someday? This is the trap of the hypothetical user. It’s easy to imagine that the product would attract a wider audience if only it had feature X. But the users you have are the users you have. Building for the users you wish you had is a form of procrastination. It avoids the hard work of serving the people who are already there.

The fourth question is: can this wait? Most features can. The urgency is usually an illusion, a product of enthusiasm rather than necessity. A feature that’s truly important will still be important next month, after the current work is done. The discipline is to write the idea down, put it in a list, and return to it when there’s space. Most ideas don’t survive that waiting period. They fade, revealing themselves as passing whims rather than genuine needs.

The Art of the Backlog

That last point deserves more attention. A backlog is not a graveyard. It’s a place where ideas go to wait, and waiting is a form of testing. An idea that still seems important after three months of sitting in a list has earned a claim on your attention. An idea that you’ve forgotten about until you scroll past it was never that important.

The backlog also serves a psychological function. It lets you say no without feeling like you’ve lost something. The idea isn’t dead—it’s just not now. For a solo developer, this is crucial. The mind needs a place to put things. If there’s no backlog, every idea feels urgent, and every no feels like a rejection. With a backlog, the no becomes a deferral. The idea is still there, waiting, and if it’s truly good, it will resurface when the time is right.

I keep a running list of TrailStudio features I’ve chosen not to build. Some of them are small—a keyboard shortcut customizer, a dark mode toggle. Some are large—a plugin system, a collaboration mode, a mobile companion app. Every few weeks, I look at the list. Most of it stays where it is. A few items get crossed off because they’re no longer relevant. Occasionally, one gets promoted to the actual roadmap because something has changed—a user request, a technical development, a shift in my understanding of the product. But the promotion is rare. The backlog is mostly a list of things I’m glad I didn’t build.

Focus Is a Feature

The products that endure are almost always focused. They do one thing well, and they refuse to do everything else. This is true of tools like Sublime Text, which has resisted becoming a full IDE for years and remains beloved for its speed and simplicity. It’s true of companies like Basecamp, which has built a sustainable business by saying no to the feature wars that consume its competitors. It’s true of countless small utilities and niche tools that have loyal users precisely because they don’t try to be everything.

For a solo developer, focus is not just a product strategy. It’s a survival strategy. The scope of what one person can build and maintain is limited, and every yes reduces the space for the next yes. The only way to make progress is to be ruthless about what matters and to let everything else go.

This is not easy. The urge to add is powerful. Every feature seems like an opportunity, and every no seems like a loss. But the reality is the opposite. Every no is a choice to protect the thing you’re building from the chaos of infinite possibility. Every no is a statement about what the product is and what it isn’t. Every no is an act of clarity. And clarity, for a solo developer, is the difference between a product that ships and a project that never ends.