5 Questions I Ask Every Founder Before Building
Most agencies take a brief and start coding. We do not. We start with questions, and the answers often change everything. Sometimes they change the entire project. Sometimes they stop it.
That is not a failure. That is the most valuable thing a discovery call can produce.
After working with over ten startups, we keep coming back to the same five questions. Not because they are clever, but because they cut through the noise faster than anything else.
One: Who Is This For?
Not "everyone." Not "small businesses." A specific person with a specific problem. If you cannot name them, describe their day, and explain why they are frustrated, you are not ready to build.
This sounds basic, but most founders skip it. They have a vision for the product but not a clear picture of the person using it. The result is features built for imaginary users. Real users behave differently than the ones in your head.
The sharper your answer here, the fewer wrong turns you take later.
Two: What Will They Pay For?
Not what features they will use. What outcome they will pay money for. Features are means to an end. Nobody pays for a dashboard. They pay for the insight the dashboard gives them. Nobody pays for notifications. They pay for not missing something important.
If you cannot connect your feature list to a specific outcome someone would open their wallet for, the feature list is wrong. You might still build a product people use. You will not build one people pay for.
The question is not "what can we build?" It is "what will someone pay to have solved?"
Three: What Happens If This Does Not Exist?
This is the question that stops most projects. And it should.
If the answer is "they will use Excel" or "they will do it manually," good. That is a real problem. People are already spending time and effort on a workaround. You are replacing something painful with something better.
If the answer is "they just would not do it," pause. You might be solving a problem nobody has. A product that replaces nothing competes with the most powerful force in software: doing nothing. And doing nothing always wins unless the pain is real.
Most projects that fail do not fail because the execution was bad. They fail because the problem was not painful enough for anyone to care about the solution.
Four: What Is the Smallest Version That Is Valuable?
Not the vision. Not the roadmap. The first thing you can charge for. If you cannot describe it in one sentence, it is too big.
Founders consistently overscope their first version. They want user roles, analytics dashboards, integrations, and admin panels before they have a single paying customer. Every extra feature is a bet that you know what users want before you have talked to them.
- Start with one workflow. The core action that delivers value.
- Skip the admin panel. You can manage things manually for the first 50 users.
- Skip integrations. Nobody needs Zapier hooks when you have 10 customers.
The goal of the first version is to learn, not to impress.
Five: How Will People Find This?
Distribution is half the battle. If you do not have an answer beyond "we will figure it out," stop building and figure it out first.
The best product in the world does not matter if nobody knows it exists. And "build it and they will come" has never worked in software. Not once. You need a channel. SEO, a community, a newsletter, a sales motion, partnerships. Something concrete.
Many founders spend $50K building a product and $0 figuring out how to get it in front of people. That is backwards. Build the audience before the product if you can. If you cannot, at least have a plan.
If you do not have strong answers to questions 3 and 5, that is not failure. That is learning. Better to find out now than after months of development.
Good Questions Save Bad Projects
We would rather have an uncomfortable discovery call than a comfortable project that goes nowhere. Saying "let us slow down" at the start is cheaper than saying "we should have thought about this" three months in.
Ask yourself these five questions before you hire anyone. The answers will tell you whether you are ready to build, or whether you have more homework to do first.
