What to build: the first step to PMF when building is no longer the hard part

If you came here from reddit/X this is the blueprint.

My name is Nick, i'm a 32 yo father and I'm the founder of Lotus and other 12 companies.

Quick context on why I wrote it. I've spent the last 17 years building. Started as a freelance designer taking small gigs to put food on the table. Today I run an agency of 30+ people building 10+ startups in parallel, and I've worked with founders on more than 200 products along the way.

Building while my wife was on labor.

The journey was messy. A lot of wrong bets, wasted years, failed products, hard lessons. But one pattern showed up so consistently across those 200 products that it stopped being a hunch and started being a rule:

What you choose to build matters more than how fast you build it.

Most founders don't lose because they can't execute. They lose because they picked the wrong problem, the wrong market, or the wrong timing and executed beautifully on all three.

Building is no longer the hard part

Claude Code, Codex, Cursor, the whole wave of coding agents, the capability gap closed. You can ship a product in a weekend. You can validate an idea in a week. You can go from zero to a live URL faster than you can schedule a meeting to debate whether the idea is good.

None of that guarantees anything.

The bottleneck moved. It's not can we build it? anymore. It's can we build the right thing fast enough to keep the users we're about to win?

That gap between "I built something" and "people are paying for it" is still brutally hard to cross. PMA, PMF, call it what you want. The bridge is the same.

This post is about step one: choosing what to build so that bridge is actually crossable.

The five-question filter

Before you open the editor. Before you write a single line. Before you buy the domain.

Run the filter.

1. What niche do you actually live in?

Not "I read about it on Hacker News." Actually lived in.

You worked the job. You've felt the problem in your own hands. You use the jargon without looking it up, and you know which parts of the workflow are broken versus which parts just feel annoying on a bad Tuesday.

Of the builders I've watched break out, almost all had 3+ years of direct experience in their niche before they started. None had under a year. Domain expertise beats raw technical skill roughly 10 to 1 and AI made that ratio even more lopsided, because the technical part is now shared infrastructure.

When you build inside a space you understand, the small decisions get easier. What to name things. What to strip out. What to obsess over. Outside it, every decision takes twice as long and still lands slightly wrong.

2. What do people here complain about constantly?

Not "would be nice to have." Actually painful.

Does it cost them time? Money? Deals they otherwise would've closed?

If the problem doesn't fail at least one of those tests, people might nod politely at your demo. They won't open their wallet.

The shortcut: watch what your target user writes angry posts about on X. Read the Reddit threads with 80 comments. Listen to the messages in your own inbox if you've shipped anything adjacent. The things people repeat unprompted, in their own words, are the things they're already willing to pay to make go away.

3. Who do you already have access to?

Can you name ten people, right now, who'd install your beta tomorrow?

Not hypothetically. Actually. Names you could DM tonight.

If you can't list ten, distribution is your real problem not the product. Spend the week building that list instead of building the app.

Good access looks like:

• You work in the industry and have peers on Slack
• You run a community or newsletter where these people hang out
• You've posted in this space long enough that people reply to you
• Former coworkers who'd happily test it for you

Distribution before product. It's almost always the right order.

4. What's your unfair advantage?

Not "I'm smart." Not "I'll out-hustle them." Those are table stakes now.

A real unfair advantage is something other builders literally cannot copy without starting two years earlier than you did:

• You know every buyer in this category by first name
• You have 10k+ followers in the niche
• You've done the job for five years and the workflow is muscle memory
• You run a community of the exact people you'd sell to
• You have insider access data, relationships, reputation that isn't buyable

If you can't answer this honestly, pause. "Better UI" is not an advantage. "I care more" is not an advantage. Your edge has to be structural.

5. Why hasn't someone already built this?

Good answers:

• It's too narrow for a VC-backed company to bother with
• You need industry context to even see the problem
• The technical barrier just dropped AI, a new API, a platform shift
• The previous generation of tools was built for a buyer that no longer exists

Bad answers:

• "Nobody's thought of it." They have.
• "Big companies don't care." They might. And the moment you show traction, they'll care fast.

The validation checklist

Before you write a line of code, make sure you can check all five boxes:

• The problem is expensive. Time, money, or revenue at least one.
• Current solutions are actively bad. Too complex, too expensive, too incomplete, or non-existent.
• You can reach 100 potential users. Write the list. If you can't write it, build the list before you build the product.
• The market can pay a price that makes sense. Rough ranges: $5–20/mo for consumer, $20–100/mo for professional tools, $50–500/mo for B2B SaaS.
• You can actually ship it fast. CRUD apps, dashboards, AI-native features, payments, auth, mobile with standard flows all fine. Real-time multiplayer, video processing, hardware, deeply custom algorithms those still take real time.

Crossing those five doesn't guarantee a business. It just means you've skipped the worst failure mode building for months toward something nobody wanted.

What not to build

"Uber for X"

Two-sided marketplaces have a chicken-and-egg problem that takes years and operations headcount to crack. If you need 100 suppliers and 100 customers in the same city to make it work, it's not a builder business. It's a funded one.

"Like Notion, but slightly better"

Incumbents own distribution. Nobody switches tools for a 10% improvement.

The only version that works: you're 10x better on one specific axis that matters to a specific user. "A better Notion" dead on arrival. "Notion for medical residents tracking caseload" maybe.

Ideas you can't explain in one sentence

If the product takes three paragraphs to describe, the problem isn't clear in your own head yet. Go back to step one.

Figure out monetization before the first commit

If you can't answer "why would someone pay me $X per month for this, starting day one?" you don't have a business idea yet. You have a feature. Features don't pay the rent.

This is the single most common thing I see builders skip. They ship something interesting, get some users, watch the graph go up, and then spend three months trying to reverse-engineer a pricing model out of a product that was never designed to charge for anything.

Design the business first. Build the product second.

Don't chase virality

Viral isn't a strategy. It's an outcome.

You can't predict it. Viral traffic converts poorly. A spike isn't a business.

The builders I know who've shipped real revenue did it with two things:

1. Genuine closeness to a specific group of users
2. Shipping what those users asked for, faster than anyone else could

That's the whole formula. Community plus speed.

The part most builders get wrong and where PMF actually dies

If you have domain expertise and distribution, you're already ahead of 95% of people about to ship their next side project.

The only real thing left is the part nobody talks about: the gap between "a user just told me what they want" and "the thing they wanted is live."

That gap is where PMF dies.

I've watched it play out on dozens of the 200+ products. A founder validates the idea. Lands early users. Starts getting requests. Writes them down. The backlog grows. A week goes by. The support inbox fills up. The user who asked for the thing churns not because the product is bad, but because the fix never came. By the time it ships, the person who needed it is gone, and two new ones are asking for different things.

Building is easy now. Closing that loop between a user asking and a user getting what they asked for, in the same week, ideally the same day is the next bottleneck. It's also where the next generation of successful products will be built.

Pick the right problem. Validate against the filter. Then obsess over how fast you can turn what users tell you into what users get.

That's the bridge. That's the whole game now.