How I Decide What to Build Next at a One-Person Studio

The One-Sentence Test I Run Before Anything Becomes an Idea

I get more ideas than I could ever build. That is not a boast, it is a liability if I do not manage it, because every one of those ideas feels exciting for about twenty minutes, and excitement is a terrible filter for what is actually worth my evenings. So before an idea is allowed to sit on any kind of list, it has to pass one test: can I describe the smallest useful version of it in a single sentence, with no "and" in the middle.

That sounds small, but it kills more ideas than any other step in the process. "A tool that tracks my Claude usage and also shows analytics and also has a community feature" does not pass. "A tool that warns me before I hit my usage limit" passes. The first sentence is a pitch for a platform. The second sentence is a pitch for a Tuesday evening. I want the second kind, because the second kind is the one I actually finish.

I did not always work this way. Early on, an idea earned space on my list the moment it sounded interesting, and my list grew into a graveyard of half-described plans that all needed a paragraph to explain. A paragraph is a warning sign now, not a feature. If I need more than one sentence to say what the smallest version does, the idea has not actually taken shape yet, it has just acquired enthusiasm, and those are different things.

The test also forces honesty about scope early, before I have sunk any real time into something. An idea that needs "and" is usually two or three ideas wearing a trenchcoat, and pulling them apart at the sentence stage is far cheaper than pulling them apart three weeks into a build when I finally notice the scope creeping. I wrote about the cost of not doing this early enough when I covered why I keep shipping small tools instead of one big product, and the honest answer is that most of that discipline actually starts here, at the sentence, long before any code exists.

The Reasons an Idea Gets Cut Before I Ever Open an Editor

Ideas that pass the sentence test still get cut constantly, and almost all of them fail for one of three specific reasons rather than a vague sense that they are not good enough.

The first reason is that the idea only sounds good because it is new. Novelty is the cheapest kind of excitement there is, and it fades fast. My check for this is simple, I let a sentence sit for at least a few days before deciding anything. If it still sounds worth building after the initial spark wears off, that is a real signal. If it only sounded good the night I thought of it, it usually was the night talking, not the idea.

The second reason is that it duplicates something I already ship, even if the wrapping is different. Every new idea gets compared honestly against what already exists across the studio, Git Dojo, OhNine, Statusline Builder, Claude Blueprint, RAXXO Studio, and the merch line. If the honest answer is "this is basically OhNine with a different name," it does not get built as a new thing, it gets folded into a note about improving OhNine instead. Chasing the same underlying problem twice under two different names wastes attention that either version could have used fully.

The third reason is that I cannot picture a specific person hitting the specific problem it solves. Not a demographic, an actual moment. With Git Dojo, the moment was clear: someone typing their first `rebase -i` and freezing because a mistake here feels expensive. When I cannot picture that moment, concretely, the idea usually stays abstract forever, which is a strong sign it was solving a feeling rather than a problem.

Cutting ideas this way used to feel wasteful, like I was throwing away potential. I have come around to seeing it as the opposite. Every idea I cut early is time I get to spend finishing something else instead of starting a fourth unfinished thing. The structural side of keeping separate products separate, rather than merging cut ideas back into existing tools out of guilt, is something I worked through when I wrote about structuring a monorepo for multiple products, and the two disciplines reinforce each other, cut hard up front, keep what survives cleanly separated after.

What Actually Earns an Idea a Build Slot

Surviving the cuts is necessary but not sufficient. An idea earns an actual build slot only once it clears one more bar, I need to have hit the underlying problem myself, more than once, in a way specific enough that I can describe exactly what a fix would look like.

This rule exists because I do not trust my own guessing about what other people need. I trust what I have personally run into, repeatedly, because repetition is the part that separates a real recurring problem from a one-off annoyance I will never think about again. Statusline Builder exists because I kept hand-editing the same kind of JSON configuration for a statusline and kept making the same small mistakes doing it by hand. That was not a hunch about what developers might want, it was an annoyance I personally repeated enough times that building the fix stopped being optional.

The specificity requirement matters just as much as the repetition. "I want better developer tools" is not specific enough to build from, it is a mood. "I want to practice `rebase` on a repo where a mistake costs nothing" is specific enough to sit down and start on the same day. When an idea reaches that level of detail on its own, without me forcing it there, that is usually the clearest signal I have that it is ready.

There is a quieter check underneath both of these, which is whether I can imagine explaining the finished thing to someone in one sentence, the same test from the very start, just applied a second time to the result instead of the pitch. If the finished version still needs a paragraph to explain what it actually does, something drifted during the build, and that is worth catching before launch rather than after. I have written before about the review pass I run on everything before I call it shipped, and this sentence-level check is really the earliest version of that same habit, just applied to an idea instead of a finished product.

None of this is a guarantee an idea will turn out well. It is a guarantee that the ideas which do get a build slot at least started from something real, a repeated, specific, describable problem, rather than a mood that felt like one for an evening.

The Maybe-Later List I Deliberately Ignore

Not every idea that fails the cuts gets deleted. Plenty of them go onto a separate list I think of as maybe-later, and the deliberate part is how rarely I actually open that list on purpose.

The temptation with any backlog is to treat it as a living thing that needs constant tending, reordering priorities, rereading old entries, making sure nothing gets forgotten. I used to do exactly that, and it quietly turned into its own form of procrastination, reviewing a list of things I am not building instead of building the thing in front of me. Now the maybe-later list gets opened at set moments only, mainly when I am between builds and genuinely have room for something new, not whenever I feel like browsing old ideas for a dopamine hit.

Most entries on that list never graduate. An idea sitting there for months without anything about my own situation changing is usually a sign the idea was never that strong to begin with, it just avoided getting cut outright at the time. The ones that do graduate almost always do so because something concrete changed, I hit the same problem again somewhere else, or a tool I already ship revealed a gap that the old idea happens to fill exactly.

I have also learned to let ideas quietly die off that list without ceremony. Not every idea needs a formal rejection, some just stop being relevant as the studio's actual products change shape around them, and pruning a stale idea costs nothing compared to what it costs to keep reconsidering it every few weeks out of a vague sense of obligation. The same instinct that keeps five separate tools from merging into one bloated platform, described in more detail in what running a one-person studio actually looks like day to day, is the instinct that keeps this list from turning into a second, quieter form of scope creep, just deferred instead of shipped.

Bottom Line

The filter is simple on paper, one sentence, no "and," survives a few days of not sounding exciting, does not duplicate something that already ships, and traces back to a specific problem I have actually hit more than once. What makes it work is refusing to skip steps when an idea feels urgent, because urgency is exactly the feeling that used to talk me into building things I never finished.

None of this makes me immune to bad calls, and I still cut ideas some weeks that probably deserved more patience. But the alternative, building whatever feels exciting in the moment, is the version of this studio that never shipped anything past a rough draft. The filter is not there to make ideas perfect. It is there to make sure whatever survives it actually gets finished.

If there is one habit underneath all of this worth naming on its own, it is patience with the cutting. Every idea I let die at the sentence stage, or at the repetition check, or quietly on the maybe-later list, is time that goes back into finishing something that already earned its place. That trade is not glamorous, and it does not feel like progress in the moment a good-sounding idea gets cut. It looks like progress later, in the list of things that actually shipped.