Most business ideas that fail were never evaluated — they were felt. The founder had a conviction, built something, and discovered the problem only after significant investment of time, money, and organizational energy. The evaluation didn't happen because it seemed unnecessary when the idea was obvious, or because the founder feared that rigorous evaluation would kill an idea they were excited about.
The second concern is worth taking seriously. Evaluation does kill ideas — but it kills the ones that should be killed. The ideas that survive a real evaluation are substantially more likely to become businesses. The discomfort of evaluation is the cost of not building the wrong thing.
I've evaluated dozens of business ideas before committing to build any of them, across technology, agriculture, education, and e-commerce in the Philippines. Some of those evaluations confirmed the idea. More of them revealed problems that caused me to restructure significantly or stop entirely. What follows is the framework I actually use — seven questions that predict whether an idea becomes a sustainable business.
Why Standard Frameworks Are Insufficient
The conventional business idea evaluation toolkit — market size, competitive analysis, unit economics — is useful but insufficient. It answers the question "is there a market?" but not "can this particular organization build and sustain a business in this market?" These are different questions, and the second one is more predictive of outcomes.
Large market size doesn't protect you from a flawed customer acquisition model. Strong unit economics at scale don't help you survive to scale. A weak competitive moat can be real even in a fragmented market. The standard framework identifies market opportunity. It doesn't evaluate whether you can execute reliably, whether customers will stay, or whether the business survives its first serious failure.
Lean startup methodology adds something important: validate before you build, test assumptions with minimum viable experiments, and iterate toward product-market fit. This is correct and necessary. But it answers a different insufficient question: "will customers try this?" rather than "will customers keep paying for this and will the organization survive long enough to find out?" Validation experiments are designed to confirm demand. They rarely surface the structural problems that kill businesses in the second and third year — the scaling problems, the customer retention gaps, the operational complexity that grows faster than revenue.
The seven-question framework that follows is designed to ask the questions that market sizing and MVP validation don't answer.
The 7-Question Pre-Commitment Evaluation
Question 1: Who specifically will buy this, and why will they choose it over what they're doing now?
"Businesses in the Philippines" is not a customer. "Agricultural cooperatives with 200-500 members in Luzon that are currently managing member records in spreadsheets and facing audit pressure from their federation" is a customer. The specificity matters because it determines whether your solution actually fits the problem, and because it determines whether you can find customers efficiently.
The second part of the question is equally important: why will they choose this over what they're doing now? "What they're doing now" is always the primary competitor — not your named competitors. Every customer has a current solution, even if that solution is a manual process or nothing at all. If you can't articulate specifically why this customer would switch from their current approach, you don't have a customer yet — you have an assumption.
For Bayanihan Harvest, the answer to Question 1 was specific: cooperatives under BIR audit pressure, with federations requiring digital records, led by managers who had tried spreadsheets and found them unmanageable at cooperative scale. They would switch because audit compliance was a legal obligation, not an optional improvement. That specificity shaped everything about how the product was built and how it was sold.
Question 2: What keeps them paying?
Initial purchase and continued payment are different decisions driven by different factors. Many businesses are good at generating initial purchases and poor at generating renewals. Understanding the renewal mechanism before you build tells you whether you have a business or a one-time transaction engine.
The questions within Question 2: Is the product embedded in a workflow that makes switching costly? Does the product deliver ongoing value, or does its value diminish once the initial problem is solved? What would cause a customer to stop paying, and how likely is that trigger to occur?
A business where customers stay because switching is costly is more durable than one where they stay because they're satisfied. Satisfaction is easy to disrupt — a competitor with a better product or a lower price can overcome it. Switching costs are structural — they persist even when a better option exists.
Question 3: What is the mechanism by which revenue grows?
Revenue growth mechanisms fall into a small number of categories: more customers, more revenue per customer, or both. But the mechanism matters as much as the category. Acquiring more customers requires a repeatable, scalable channel — the question is whether such a channel exists at a cost that leaves margin. Growing revenue per customer requires either expansion into more of the customer's spending or genuine upsell paths.
The revenue growth mechanism predicts whether you'll need to raise capital, how long the runway to profitability is, and what organizational capabilities are required to grow. A business that grows through word-of-mouth referrals requires a different organization than one that grows through direct sales. A business with high natural expansion (customers who grow their own usage over time) requires less customer acquisition investment than one that churns and must constantly replace customers.
Question 4: What is the competitive moat, and when does it activate?
A moat is a structural advantage that makes you harder to compete with over time. Network effects, data advantages, switching costs, proprietary infrastructure, and brand trust are the common categories. The important discipline is being specific about which moat applies to your business and when it begins to matter.
Most early-stage businesses have no moat. They have a first-mover advantage that lasts until a well-funded competitor enters or until the market matures. This is acceptable — you don't need a moat to start a business. But you do need a theory of how a moat develops as you grow. If your honest answer is "we'll have to compete on price and execution forever," that's a viable strategy — but it means the business can never afford to relax, and every efficiency in operations is a survival requirement rather than an optional improvement.
Question 5: What is the operational complexity, and does it scale?
Some business ideas are more complex to operate than they appear from the outside. The complexity often lives in the coordination layer — how many parties have to coordinate for each transaction to complete, how much human judgment is required for each decision, how many exceptions occur relative to standard cases.
High coordination complexity businesses are not inherently bad, but they scale slowly and require more organizational investment per unit of revenue. Agricultural supply chain platforms, cooperative management systems, and multi-party marketplace models all have higher coordination complexity than, say, a SaaS product with a self-service sign-up flow. Understanding this complexity before building determines whether your financial model is realistic, whether your hiring plan makes sense, and whether your timeline to profitability is achievable.
Question 6: Does your profile fit this business?
Founder-market fit is a real variable, and it's underweighted in most business evaluations. The question is not whether you're passionate about the idea — passion is necessary but not sufficient. The question is whether you have, or can realistically acquire, the capabilities the business requires to succeed.
A technology founder building a platform for agricultural cooperatives needs either agricultural cooperative expertise or the ability to acquire it quickly, and a credible path to being trusted by the people they're serving. A founder building an education platform needs either deep pedagogical expertise or close relationships with educators who will provide it. The gap between what the business requires and what the founder brings is a risk that compounds over time — it doesn't close automatically as the business grows.
This is not about disqualifying founders from markets they don't come from. It's about being honest about the gap and planning specifically for how to close it, rather than assuming it will resolve itself.
Question 7: What does failure look like, and can the business survive it?
Every business makes serious mistakes. The question is whether the first serious mistake kills the organization or damages it in recoverable ways.
The business ideas that concern me most are those where the first significant failure — a large customer churning, a key team member leaving, a regulatory problem, a product launch that misses the mark — could be fatal. Businesses with high fixed costs, concentrated revenue, single points of operational failure, or customer bases that won't give second chances are brittle in ways that often aren't visible until the first failure hits.
The honest version of Question 7: if the single most likely serious problem occurred in year two, would the business survive? If the answer is no, or if you can't answer it, the idea needs structural modification before you build.
Red Flags That Don't Show Up in Standard Evaluation
After using this framework across multiple ventures, certain red flags appear reliably in ideas that fail while looking promising on paper.
The customer is too broad. When the answer to "who will buy this?" is a demographic category rather than a specific type of person with a specific problem, the business has not been thought through. Broad customer definitions lead to generic products that no one loves.
The revenue depends on changing behavior. Businesses that require customers to fundamentally change how they work are much harder to build than businesses that make existing behavior more effective. The switching cost runs both ways — and the cost of changing behavior is often higher than founders anticipate.
The unit economics are convincing at scale but unclear at launch. Many business ideas have plausible unit economics when the volume assumptions are met. The question is what unit economics look like at the volumes you'll actually have in year one and two. Businesses that require scale before the economics work are ventures that require external capital — and the external capital assumption should be explicit, not implicit.
The founder can't name the three most likely reasons this fails. Not the unlikely black-swan risks — the likely ones. Founders who can't name these usually haven't evaluated the idea rigorously. The ability to name the three most likely failure modes and explain why the business design addresses each of them is a reliable signal that the evaluation has actually happened.
When You Can't Run a Conventional Pilot
Some business ideas are genuinely hard to validate through conventional minimum viable product approaches. B2B enterprise software, regulated industries, multi-party platforms, and hardware-dependent products all face this challenge — the minimum viable version of the product is still expensive to build, and the sales cycle is long enough that quick validation experiments don't produce clear signals.
In these cases, the evaluation methodology shifts. Instead of validating product demand, you validate the component assumptions: Can you identify and access the specific customers you've defined? Do those customers confirm the problem diagnosis independently, without you framing it for them? Do they articulate the problem in a way that aligns with your solution approach? Have any of them tried to build a solution themselves, and if so, what did that attempt reveal?
These questions don't confirm that your solution will work. They confirm that the problem is real, that your customer definition is accurate, and that the market is accessible. That's enough to commit to building an MVP with confidence — which is a different kind of confidence than the confidence that comes from a market size slide.
After the Evaluation
A complete seven-question evaluation produces one of three outcomes: clear signal to proceed, clear signal to stop, or a conditional signal — proceed if you can resolve a specific concern.
The conditional signal is the most common and the most useful. Most ideas that survive rigorous evaluation survive with modifications — a different customer definition, a different revenue mechanism, a different approach to the moat problem. These modifications are not compromises. They're the result of the idea being tested against reality before the organization commits to building it.
The discipline is to treat the evaluation as a genuine input to the decision, not as a process you run to confirm a conclusion you've already reached. The conclusions that evaluation produces are only as useful as the honesty with which the questions are answered.
Build things that can survive being evaluated. The ideas that can't usually reveal why when you press on them.