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 attached to.
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 attached to the idea — conviction 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.
A Worked Example: One Idea Through All Seven Questions
The framework is abstract until you watch an idea move through it and change shape. Take a plausible-sounding idea: a digital recordkeeping and reporting platform for agricultural cooperatives in the Philippines — the same problem space as Bayanihan Harvest, evaluated cold, before any commitment to build.
Question 1 forces the customer from "cooperatives" to a specific profile: cooperatives with 200-500 members in Luzon, managing member records in spreadsheets, facing audit pressure from their federation. That specificity already does work — it tells you the wedge is compliance, not convenience, and that the buyer is the manager who has personally felt the spreadsheet break.
Question 2 surfaces a strength. Once a cooperative's member ledger and federation reporting live inside the system, switching means re-migrating the records that the federation audits — switching cost is structural, not a matter of satisfaction. That is a durable retention mechanism, and it shows up before a line of code is written.
Question 3 exposes a constraint. Revenue grows by adding cooperatives, but cooperatives are reached through federations and word of mouth among managers who know each other — not through a self-service funnel. So the growth mechanism is relationship-led and slower than a SaaS dashboard would suggest. That is not disqualifying, but it tells you the financial model cannot assume cheap, fast, channel-driven acquisition.
Question 5 is where this idea earns its caution. Coordination complexity is high: members, the cooperative, and the federation each touch the data, with real-world exceptions — corrections, disputed records, irregular reporting cycles — that don't fit a clean transaction flow. This predicts slow scaling and more operational investment per cooperative than a self-service product would need. A founder who skipped this question would build a financial model that assumes SaaS scaling speed and then be surprised when reality moves at coordination speed.
Question 7 names the most likely year-two failure honestly: a federation changes its reporting requirements, or one large cooperative leaves and takes referral credibility with it. The design response — keeping the reporting layer configurable rather than hard-coded to one federation's format, and avoiding revenue concentration in a single anchor cooperative — falls out of asking the question, not out of inspiration.
The idea survives the evaluation, but it does not survive unchanged. It comes out with a sharper customer, a known-slow growth mechanism, an explicit operational-complexity budget, and two structural protections against its most likely failure. That is what a real evaluation produces: not a yes or a no, but an idea that has been argued with.
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.
Where This Framework Stops Being Useful
A seven-question evaluation is a discipline, and disciplines have costs and edges. Three are worth naming so the framework is used with judgment rather than as a substitute for it.
The first is over-evaluation. The questions reward thoroughness, and a founder uncomfortable with the risk of building can hide inside the evaluation indefinitely — refining the customer definition, re-examining the moat, never committing. Evaluation is meant to reduce the cost of being wrong, not to eliminate the act of deciding. Past a certain point, the only remaining way to test an idea is to build a bounded version of it and put it in front of the specific customer you identified in Question 1.
The second is false precision. The framework produces structured, confident-looking answers, and structure can disguise that the underlying inputs are still guesses. An evaluation built on a customer interview you led, or on revenue assumptions you wanted to be true, will pass cleanly and still be wrong. The questions are only as honest as the evidence behind them, and the framework cannot enforce that honesty — only the founder can.
The third is that some genuinely good businesses fail individual questions for legitimate reasons. A business may have no moat for its first two years and still be worth building if the first-mover window is real. The framework flags this as a risk, correctly, but flagging is not vetoing. The discipline is to register the weak answer, decide consciously whether it is survivable, and write down why — not to treat any single failed question as automatic disqualification.
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.
You can start this week without building anything. Take the idea you are closest to committing to, and write a single honest paragraph answering each of the seven questions — no slides, no model, just plain sentences you would be willing to defend out loud. Where a paragraph turns vague or circular, you have found a question you cannot yet answer, and that gap is the real output of the exercise. Then test the one answer you are least sure of against a real person: for the customer question, that means one conversation with someone who matches your specific profile, where you let them describe the problem before you describe your solution. An afternoon of honest writing and one unframed conversation will tell you more about whether to build than a month of refining the idea in your own head.
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.
Continue in this series
This piece is part of The Indie Operator's Complete Guide to Running a Venture Portfolio, my systematic guide to venture building and modular architecture. Related reading:
- Founder-Market Fit: The Factor Most Venture Frameworks Skip
- How to Earn Money Online Without Building on Noise
- The Founder Bottleneck Is a Governance Problem, Not a Delegation Problem
- The Shared Services Trap: What Not to Centralize Across a Venture Portfolio
See how this plays out in practice across my portfolio of ventures.
