How I Decide What to Build Next

Key Points

Not every idea deserves to build. Ryan uses five key filters to decide what gets his time.
The “scratch your own itch” test and distribution question eliminate 90% of ideas before they start.
Sometimes the framework breaks—and that’s okay. The best projects combine signal with genuine curiosity.

I’ve started 23 businesses. Most of them should never have been built.

This isn’t a post bragging about failures—it’s a confession. I’ve wasted thousands of hours on ideas that looked good at 2am but had zero product-market fit, no clear path to users, or required so much runway that I’d burn out before shipping anything real.

The hard truth: most ideas don’t deserve your time. Not because they’re bad ideas, but because they’re bad for you. A billion-dollar idea isn’t worth anything if you can’t reach the people who need it, or if it requires you to pretend to be excited about something you’re not.

Over time, I’ve developed a pretty simple framework to separate the ideas worth building from the ones that should stay in the notes app. It’s not perfect—I still occasionally build something dumb—but it works well enough that I fail less often than I succeed.

Here’s how I think about it.

The Scratch Your Own Itch Test

This is the most basic filter. Do I personally have this problem? Am I the customer?

When I built Openmark, I was drowning in Markdown files scattered across three different apps. I needed a single place to save and reference Markdown snippets. So I built it. When I was running Rotate, our team couldn’t easily track which clients had hired which referrals, so we built an internal tool. When I wanted to understand which newsletter subscribers cared about which topics, I built Refract.

All three of these projects passed the most important test: I was using them the day I finished the MVP.

Paul Graham said something I think about constantly: “Do things that don’t scale.” If you’re not willing to do the thing yourself—even badly, even inefficiently—then you don’t believe it’s a problem worth solving. You’re just chasing some abstract notion of what a startup looks like.

The inverse is also true. If you’re solving a problem only you have, that’s not a business. But it is a valid project to build, at least for a while. Solo tools, personal experiments, weekend hacks—these can still be valuable. They’re just not company-building opportunities.

I use the itch test as my first gate. If I don’t personally feel the pain, the project goes in the “maybe someday” pile.

The Distribution Question

This kills more ideas than anything else in my framework.

Let’s say you’ve passed the itch test. You found a problem you care about. Now: how will people find out about this thing?

Not “how will we do marketing”—that’s the wrong question. I’m asking something more fundamental: can I reach the people who need this without spending money? Or at least without spending much money?

With Openmark, I knew developers use Product Hunt, Twitter, and indie hacker communities. I have some credibility in those spaces. I could probably get initial users through my network and those channels. Same with Refract—the newsletter community is small, interconnected, and I’m embedded in it.

Contrast that with an idea I didn’t build: a SaaS for enterprise project management. Sure, I could build it. But the only way to reach enterprise customers is through sales reps or enterprise trade shows. That requires budget. That requires a team. That requires something I’m not willing to bet on.

Jason Fried wrote about this in Rework: “The easiest, most straightforward way to determine if you can get customers is to get customers.” Don’t build a product you have no idea how to sell.

I think about this before writing a single line of code. If my answer is “we’ll figure out distribution later,” the project is dead on arrival. Distribution first. Then build.

The Energy Test

Can I still be excited about this at 10pm when my kids are finally asleep?

This is the one that separates projects I’ll actually finish from projects I’ll abandon in three weeks.

Some ideas are theoretically interesting but boring to execute. Migrating a database is important but tedious. Building an admin dashboard is necessary but uninspiring. I’ve learned to recognize the difference between ideas that sound cool and ideas that light me up.

The energy test is also useful for filtering out ideas that feel important because they’re trending or because I think they’d be impressive to other people. “Building an AI thing” felt like that a year ago. Most of those ideas crashed because I didn’t actually care about the problem—I cared about being seen as someone who builds AI things.

I ask myself: would I work on this without telling anyone about it? Would I build it even if nobody knew? If the answer is no, it doesn’t pass the energy test.

The Weekend Test

Can I build a working version in a weekend?

This is where scope goes to die—and that’s the point.

If the honest answer is “no, this needs six months,” I either scope it way down or I don’t start. The weekend test forces you to strip the idea to its bare bones. No nice UI, no second-order features, no “we’ll add this later.” Just the core thing that proves the concept works.

Refract started as a very simple experiment: can I help newsletter creators understand subscriber engagement? The MVP was so crude—literally just a form and some basic analytics—but it answered the question in 48 hours. I could then decide if the deeper version was worth building.

Warren Buffett’s entire investment philosophy is built on this idea: if you can’t understand it quickly, don’t do it. Same with building. If you need months just to understand if the idea has legs, the idea probably isn’t clear enough.

The weekend test also forces you to understand your own constraints. I have a day job (Rotate), I run a newsletter (Ryan’s Roundup), I have a family. I don’t have six months to experiment. So I’ve trained myself to ask: what’s the absolute minimum version that proves whether this idea is worth pursuing?

Time Horizon: Pick One and Stick With It

Here’s a mistake I made a lot early on: I’d start something thinking it was a weekend experiment, then get a little traction, then suddenly treat it like a long-term company bet. Then I’d burn out because I couldn’t maintain that energy while doing everything else.

Now I explicitly decide: is this a quick experiment or a long-term commitment? And I write that down so I don’t change my mind when the project gets interesting.

Openmark is a long-term bet. I’ve been building it on and off for two years. I’m willing to invest serious time and maybe money into distribution and product development.

Refract started as an experiment, proved the concept, and now I’m treating it like a long-term thing because the signal was strong enough to justify the investment.

Some projects stay experiments forever. They never reach “long-term bet” status, and that’s fine. They’re exploring ideas, building in public, learning. Knowing which category you’re in before you start means you won’t accidentally burn out on a weekend project or underfund a company-building effort.

The Sunk Cost Trap

This deserves its own section because it’s where most of my failed projects actually died.

You’ve built something. You’ve put in weeks or months. People are using it. But it’s not growing, and you’re not that excited about it anymore. Do you push through or do you kill it?

The sunk cost fallacy says: you invested all that time, so you should keep investing. Don’t let it go to waste. Build that feature. Run that marketing campaign. Hustle harder.

Most of the time, this is wrong.

I’ve learned to ask instead: if I were starting this project today, would I? If the answer is no, I usually kill it. The time is already gone. The only question is whether you’re willing to invest more time chasing something you don’t believe in anymore.

Sometimes I kill a project and then restart it six months later because something changed—a new distribution opportunity opened up, I had a new insight about the problem, or the energy came back. That’s fine. But I try to avoid the slow death where a project sits in maintenance mode forever, draining small amounts of energy without going anywhere.

When the Framework Breaks

Here’s the thing: sometimes you should just build something because it’s interesting. Because you’re curious. Because you want to see what you can make.

Not everything needs to pass all five tests. Not everything needs ROI or product-market fit or a distribution strategy. Some of the best things I’ve built came from pure curiosity—the kind of project where the process is more important than the outcome.

Build in public. Ship it ugly. Let yourself explore ideas without knowing where they’ll go. That’s where real learning happens. The framework is a guide, not a cage.

My best projects tend to combine two things: they pass most of the filters and I’m genuinely interested in building them. That intersection is rare, which is why I don’t start many projects. But when it happens, that’s when I move fast.

Building vs. Shipping vs. Everything Else

One more distinction worth making: starting a project and finishing one are completely different things.

I should write more about MVPs, but the short version is this—you can start a lot of things. But you should only finish things that pass most of the framework. And you should only talk about finishing things that pass even more tests.

The framework is meant to filter before you commit serious time. Once you’re actually building, different rules apply. You’re not trying to optimize for whether it was the right decision to start anymore. You’re trying to optimize for shipping something real that you can actually learn from.

I talk about building in public sometimes, and people ask me: don’t you worry about sharing projects that might not work out? My answer is no, because I’m already doing the work. I’m already committed. Sharing that process is valuable regardless of the outcome.

So the framework filters what deserves my time. Once I’ve decided it’s worth starting, I commit to shipping something real. Then I learn from what actually happened versus what I predicted would happen.

The Actual Decision

When I’m evaluating a new idea, I pull up a notes doc and I answer these questions:

Do I have this problem? (Itch test)
How would I reach people who need this? (Distribution)
Would I work on this without telling anyone? (Energy)
Can I build a version in a weekend? (Scope)
Am I committed for six months or six weeks? (Horizon)

If I answer honestly on all five, the decision usually makes itself. Three “no” answers? It’s going in the backlog. Four or five “yes” answers and I’m blocking time to start.

The framework won’t tell you which ideas are going to succeed. But it will save you from wasting time on ideas that fail for boring reasons—ideas that failed because you picked the wrong problem, or the wrong audience, or the wrong time horizon.

I’ve learned this the hard way, across 23 businesses and hundreds of failed experiments. The best filter isn’t intelligence or taste or market knowledge. It’s honesty. Honest answers to simple questions, asked before you’ve already committed emotionally to being right.

Start there. Then build.