How I Decide What to Build Next

People assume founders have a secret formula for choosing what to build. A spreadsheet, a market report, a clever framework with a name. I do not have any of that. What I have is a set of questions I ask myself every single time an idea shows up, and the discipline to walk away when the answers are bad.

I have built enough things to know that the idea is the cheapest part. Anyone can have ideas. I get new ones every week. The expensive part is the months of mornings you will spend turning one of them into something real. So the most important decision is not how to build. It is what to build, and just as importantly, what not to build.

Here is exactly how I make that decision now. It is not theory. Every step below is something I learned by getting it wrong first.

Start with a pain you have actually felt

The ideas that survive are the ones rooted in a problem I have personally experienced. Not a problem I read about. Not a problem a trend report told me is big. A problem that has annoyed me, cost me time, or cost me money.

Niguro, my search engine for Nepal, started this way. I kept searching for Nepali news and Nepali content and getting results that did not understand the country. The big search engines treated Nepal as an afterthought. That frustration was mine before it was a product. When I started building, I was building the thing I wanted to exist.

Contrast that with ideas I have chased because they sounded impressive. A few years ago I spent weeks on a project because a friend said the space was “hot.” I had no personal connection to the problem. Every decision felt like a guess. When the first hard week arrived, I quit, because I had no reason to continue besides hoping money would appear. It did not.

The rule is simple. If the problem has never bothered you personally, you will not care enough to solve it well. You will build a shallow answer to a problem you do not understand. Users can tell.

This does not mean you can only build for yourself. It means the problem has to live somewhere close to you: your work, your friends, your city, your country. The closer the pain, the clearer the picture of what “fixed” looks like.

Ask “will anyone pay” before “can I build it”

Founders love the second question. Can I build it? With AI tools today, the answer is almost always yes, and fast. That makes the question useless as a filter. The question that filters is the first one: will anyone pay for this, in money or attention?

Pay does not always mean cash. People pay with their time, their data, and their habit. But someone has to give up something real, or you do not have a product. You have a demo.

Before I write a line of code, I try to find one person who has the problem and would be relieved if it disappeared. Then I ask what they would give up to make it disappear. If the answer is vague enthusiasm, like “oh that sounds cool,” that is a no. Vague enthusiasm has never paid a server bill.

When I was shaping my book-writing workflow into a guide, I did not start with a table of contents. I started with the memory of people asking me, over and over, how I actually turn AI designs into real WordPress sites. The demand was already there in my inbox. The product was just packaging what people were already asking for.

A practical test: describe the idea in one sentence to five people who have the problem. If at least two say some version of “I need this now,” keep going. If they all say “interesting,” stop. Interesting is the most dangerous word in building. It feels like validation and means nothing.

Build the smallest version that teaches you something

Once an idea passes the first two tests, I do not plan the full product. I plan the smallest version that can teach me whether I am right.

This is where most founders, including past versions of me, go wrong. We build the complete vision in our heads. The login system, the dashboard, the settings page, the beautiful empty states. Weeks pass. Nobody has seen anything. Nobody has complained about anything, which feels like progress but is actually the absence of information.

My question now is: what is the smallest thing I can ship that gives me a real signal from a real user?

For Niguro, the first version was not a search engine. It was a news page that pulled headlines from Nepali publishers into one feed. One page, one job. If nobody visited, the bigger dream did not matter. People visited, so the bigger dream earned the right to be built.

For my AI-to-WordPress workflow guide, the smallest version was not a course. It was a short write-up of the steps I actually followed. The response told me whether a full guide was worth the weeks of work. It was.

Think of it as buying information cheaply. Every day you build without user contact, you are paying full price for guesses. The smallest version gets you answers while the cost is still low.

Talk to users, but do not obey them

Talking to users is the most quoted advice in startups, and it is also the most misunderstood. People hear “talk to users” and translate it as “do whatever users ask for.” That is a mistake. Users are excellent at describing their pain and terrible at designing the cure.

My approach: ask about their life, not your product. Ask what they did yesterday when the problem appeared. Ask what they tried. Ask what it cost them. Do not ask “would you use a feature that does X,” because they will say yes to be polite and then never use it.

When I added features to my news feed, I watched what people actually clicked instead of asking what they wanted. The clicks told a different story than the requests. Requests are wishes. Clicks are behavior. I build for behavior.

There is a balance here. Ignore users completely and you build in a bubble. Obey them completely and you build a pile of features with no soul. The founder’s job is to listen carefully to the problem and then decide the solution yourself. That is the part nobody can outsource to you.

Ask what it costs you, not just what it earns

Every idea has a price, and I do not mean money. I mean your calendar, your focus, and your other ideas.

I ask three cost questions:

First, what dies if I say yes to this? I have limited hours. Every project I take on is a project I cannot do. When I say yes to one idea, I am saying no to several I have not met yet. The idea has to be worth those invisible noes.

Second, can I maintain this? Building is the fun part. Maintaining is the real part. A product you launch and abandon damages your name more than a product you never launch. I once released a small tool, got bored, and let it rot. People who found it later assumed everything I made was like that. Lesson learned: do not start what you will not maintain.

Third, does this compound? I prefer ideas that make my future work easier. Writing about what I build teaches me and markets me at the same time. Open tools I create for one project get reused in the next. If an idea only pays once and teaches nothing, it has to be extraordinarily good to earn my time.

Say no more than you say yes

This is the hardest part, and it took me years. Saying no to your own ideas feels wrong. Each one felt exciting for a day. But an idea journal full of maybes is just a distraction wearing a productive costume.

I keep a simple list of every idea I decide against, with one line saying why. “No: no personal pain.” “No: cannot maintain alone.” “No: vague enthusiasm only.” Writing the reason down does two things. It stops the idea from circling back and wasting my time again. And it builds a record I can learn from. Patterns appear. I noticed I kept saying yes to ideas that were technically interesting but had no user waiting. So I added a rule: no waiting user, no build.

A founder who says yes to everything is not ambitious. A founder who says yes to everything is unfocused. The yes only means something because of all the noes around it.

My five-question checklist

Here is the whole process on one card. I run every idea through it, in this order:

1. Have I personally felt this pain, or is it close to me? If no, stop.
2. Can I find two people who need this now, not “someday”? If no, stop.
3. What is the smallest version that teaches me something real? If I cannot answer, the idea is too big.
4. Will I maintain this for a year? If no, stop.
5. Does it compound into my other work? If yes, it moves to the front of the line.

No idea has ever passed all five and failed me badly. Several that failed one of them have cost me months. The checklist is not magic. It is just the written-down version of every mistake I have already paid for, so I do not have to pay for them twice.

You will have your own list eventually, shaped by your own mistakes. But borrow mine until then. The goal is not to find the perfect idea. The goal is to stop building the wrong ones, so you have the time and energy left for the right one when it arrives.