Stop building things nobody wants
How to validate a product
There is a tragedy that repeats every weekend in the tech world. A talented engineer wakes up with a spark of inspiration. They open their IDE, spin up a new Next.js repo, configure Tailwind, set up the database and code furiously for 48 hours. On Sunday night, they deploy. They post the link on X or LinkedIn, waiting for the applause.
And then... silence. No signups. No feedback. No revenue. Just a server bill and a bruised ego.
Why does this happen? Because as engineers, we are trained to solve technical puzzles. We get our dopamine hit from “getting it to work”. But the market doesn’t care about your architecture. The market only pays for the value you deliver.
If you want to transition from a Coder to a Builder, you must fix the biggest bug in your operating system: The “Solution-First” Mindset.
1. The Two Types of Risk
To understand why we fail, we need to distinguish between two types of risk.
Technical Risk: “Can this be built?”
Example: Can we build a fusion reactor? Can we build a bridge to Mars?
Reality: For 99% of SaaS ideas, the Technical Risk is zero. You know you can build a To-Do app. You know you can build a CRM. The question isn’t can you, but should you.
Market Risk: “Will anyone pay for this?”
Example: Does the world need another project management tool? Will people pay for an AI recipe generator?
The Trap: Engineers love mitigating Technical Risk because it’s within our control. It feels like work. It feels productive. But successful Builders obsess over Market Risk. They refuse to write a single line of code until they have proof that the problem exists and is painful enough to warrant a solution.
2. How to find “Boring” Problems
If you shouldn’t start with code, where do you start?
You start with Friction.
The best business ideas usually don’t look like “revolutionary tech”. They look like frustrated people trying to do their job. Don’t look for “cool” ideas. Look for “Boring” problems.
Here is a heuristic to find them:
The Excel Index: If a business is running a critical process on a messy, shared Excel file that crashes every day, that is a SaaS product waiting to be built. Excel is the biggest competitor of B2B SaaS, and it’s vulnerable.
The “Copy-Paste” Loop: If a human is manually copying data from an Email to a CRM, or from a PDF to a spreadsheet, that is an automation script people will pay for.
The “Bleeding Neck”: In sales, they distinguish between “Vitamins” and “Painkillers”.
Vitamin: “An app to organize my bookmark collection”. (Nice to have, but nobody pays).
Painkiller: “A tool that stops my AWS bill from exploding”. (Must have. Companies will throw money at you).
Rule of thumb: If the problem doesn’t annoy the user enough to make them open their wallet, it’s not a business. It’s a hobby.
3. The Validation Stack (Before npm init)
So, you found a potential problem. Your fingers are itching to type npm init. Stop.
Writing code is the most expensive way to test an idea. It costs time, energy and server money. You need to run a Validation Algorithm first.
Step 1: The “Smoke Test” (The Doorway)
Build a simple Landing Page. Do not build the app. Use a no-code tool (Framer, Carrd) or AI to spin it up in an hour. Describe the value proposition clearly: “I help [Target Audience] solve [Problem] by [Solution]”. Add a “Join Waitlist” or “Buy Now” button.
Run $50 of ads or post it in relevant communities (Reddit, niche forums).
If nobody clicks? You just saved yourself 3 months of coding. Kill the idea.
If people sign up? You have a signal. Proceed to Step 2.
Step 2: The “Mom Test” (The Interview)
You need to talk to humans. But be careful: if you ask your mom “Is my idea good?”, she will lie to protect your feelings. You need to use The Mom Test method (by Rob Fitzpatrick).
Bad Questions (Hypothetical):
“Would you use this app?”
“How much would you pay for this?”
“Do you think this is a good feature?”
Good Questions (Historical):
“Tell me about the last time you encountered this problem.”
“How do you currently solve it?”
“How much does that current solution cost you (in money or time)?”
“Have you tried looking for other solutions? Why didn’t they work?”
If they aren’t already trying to solve the problem (even clumsily), they won’t buy your software.
Step 3: The “Wizard of Oz” MVP
This is the ultimate secret of Solopreneurs. In the movie The Wizard of Oz, the scary giant head was just an old man pulling levers behind a curtain. You can do the same.
Don’t build the backend automation yet. If you are building an “AI Logo Generator”, put up a form. When a user submits a request, you generate the logo manually (or use Midjourney) and email it to them. From the outside, it looks like software. On the inside, it’s just you.
This allows you to test if people are happy with the output without building the engine. Do this until the manual work becomes too much to handle. Then write the code to automate yourself out of the loop.
4. Handling the Pivot
What happens if the validation fails? What if nobody signs up for the waitlist?
Celebrate. Seriously. You just avoided the most common failure mode in our industry: building a ghost town. Validation is not about proving you are right; it is about finding the truth.
In 2026, the cost of trying an idea is near zero. The “Builder” is not someone who never fails. It is someone who fails fast and cheap.
Coder: Spends 3 months building -> Fails -> Quits.
Builder: Spends 3 days validating -> Fails -> Pivots -> Wins.
Conclusion: Fall in love with the Problem
The transition from Coder to Builder is painful because it requires us to suppress our builder’s instinct. It requires us to spend time in the “messy” real world, talking to humans, understanding their boring struggles and facing rejection.
But this is the only way to build something that lasts. The world doesn’t need another To-Do List app built with the latest JS framework. It needs solutions to real, expensive, boring problems.
Don’t write code to prove you are smart. Write code to make a problem disappear.