Reviewers Aren't Looking for a 'Great Idea' — They're Looking for a Business That Works: A Pre-Submission Self-Check

#Reviewers Aren't Evaluating the 'Idea' — They're Evaluating Whether It's 'a Business That Works'

Reviewers look at a lot of applications in a short amount of time. In that window, they're asking one thing: "does what this person described actually work as a business?" Not how clever the idea sounds, but whether the conditions around that idea line up and function together.

Those conditions break down into four lenses: market viability, customer acquisition, validation, and profitability. The key is that all four need to stand together. If even one is missing, the evaluation tilts toward "nice idea, not sure it's a business."

#The Six Questions in a Reviewer's Head — Answer Them With Your Own Plan

Turn the four lenses into an actual check and you get six questions. Close your plan and try answering each of these six in one sentence. Whichever question you get stuck on is your weak spot.

These six questions apply almost as-is regardless of industry. If the answer comes easily, that section of your plan is solid; if you can't compress it into one sentence, there's a good chance it's written vaguely in the plan too. Flag whichever boxes you get stuck on, and that list becomes your to-do list.

#Define Yourself Before You Get Mistaken for a Familiar Category

In a short window, reviewers try to slot your plan into a familiar category to make sense of it fast. If you don't define your position first, you get read as a common, ordinary category — and scored at that category's average.

That's why you need a one-line self-definition. In the form "we're not A, we're B," you preemptively deny the easy-to-assume category and pin down your real position. For example, if there's a risk of being read as "just another app that aggregates and displays information," you draw the line yourself: "not just information delivery — a tool that connects all the way through to a decision."

#When You Don't Have Customers Yet — Validation Doesn't Have to Be Elaborate

At the pre-launch or early stage, having no customers is normal. Reviewers know this. But "we have no customers" and "we don't know how to find customers" are different things. Only the latter costs you points. So you need to clearly state four things: who your first customer is, where you'll meet them, how you'll test, and how you'll confirm willingness to pay.

Validation doesn't require big data. A small confirmation is enough. Even one result — interviewing a handful of prospective customers and finding the same complaint repeats, or testing usage and payment intent with a small group — moves you from "guess" to "evidence."

• Customer interviews — whether the same complaint keeps repeating
• A short survey — the frequency and intensity of the problem
• Landing page / waitlist signup — actual clicks and registrations
• Community reaction — response in the places your target audience gathers
• Prototype / pilot — behavior once it's actually in someone's hands
• Market research — external evidence backing up size and trend

What reviewers actually want to see in the validation section isn't the size of the result. It's the flow: "what did you confirm, and what will you validate next as a result." Even a small result reads as "a team that knows how to run a business" if it leads into the next hypothesis.

#A Revenue Model Is 'the Reason to Pay,' Not 'the Billing Method'

Plenty of applications just write "subscription" or "ad revenue" in the revenue model box. But the name of a billing method isn't an answer. What reviewers are checking is "why would the customer pay for this problem, right now."

A strong revenue argument usually has a similar shape: "because we reduce the time or money the customer currently spends on this problem, we take a share of that saved amount." Payment follows naturally as the result of a value exchange. On the other hand, "gather people for free first and monetize with ads later" reads as a weak signal. It means the reason to pay right now is missing.

#Execution Ability — 'Why You Can Do This,' Not 'That You Want To'

Finally, reviewers check "why specifically you can pull this off." The same plan reads differently coming from a team with grounds to execute it versus a team with only enthusiasm. The core is pulling "why you can do this" out of your background, rather than just "why you want to."

Whatever your background, it becomes an angle, not a weakness. What matters is connecting that background to a specific part of the business. One sentence — "I experienced this problem myself, and that's why I've already done ___" — is what brings the execution-ability section to life.

#Pre-Submission Self-Check — the 7-Element Plus 6-Question Checklist

Lay everything above on top of a typical application's structure and you get seven elements. The order is also the flow of the story: problem → solution → customer → differentiation → validation → revenue → execution ability. Rather than writing at length, the key is filling each box with one or two sharp sentences. A missing box is your weak point.

1. Problem — did you state in one sentence who has what pain point right now
2. Solution — is it clear how you solve that problem
3. Customer — is the target specific, not a blanket "everyone"
4. Differentiation — is there a reason you're better than the existing way of doing this
5. Validation — what did you confirm, and what will you validate next
6. Revenue — is it clear why the customer would pay right now
7. Execution ability — is there evidence for why you specifically can do this

Now layer the six questions on top and answer them one more time. If all seven boxes are filled and you can answer all six questions in a single sentence each, you can avoid the "nice idea, not sure it's a business" verdict no matter which reviewer you draw.

1. I can say in one sentence who uses this service
2. I know specifically what problem they have right now
3. I can state in one sentence what's better than the existing way of doing this
4. I know exactly where I'll meet my first customers
5. I can explain how I make money, down to the reason customers would pay
6. I know exactly what I'll validate next

It's hard to run this check alone — your own blind spots in your own writing are hard to see. You're too close to it, so you skip over things assuming "that's obvious." Getting a third party to confirm whether the seven elements and six questions are actually filled in lets you patch weak spots before you submit that you assumed were "too obvious to write down."

#Frequently Asked Questions (FAQ)

Q. If the idea is genuinely original, can't the other boxes be a little empty?

A. Originality alone rarely gets you through. Right after a novel idea, reviewers immediately ask "so does this work as a business." If any one of market, customer, validation, or revenue is empty, you get tagged with a "nice idea, but..." qualifier, and that qualifier costs you points. Originality is a starting point, not a finish line.

Q. I'm pre-launch with no customers and no revenue — how do I fill in validation?

A. Use small confirmations instead of big metrics. Things like the same complaint repeating across prospective-customer interviews, a waitlist filling up on a landing page, or a small-scale usage and payment-intent test. The flow — what you confirmed and what you'll check next — matters more than the size of the result.

Q. Why is just writing "subscription" in the revenue model box weak?

A. Because the name of a billing method only answers "how you'll collect it," not "why they'd pay." If it's visible that you're reducing the time or cost the customer currently spends on this problem — a value exchange — then subscription or a commission both become believable. The reason to pay comes first; the method's name comes second.

Q. Is it enough to run this self-check alone before I submit?

A. To some extent, yes. But it's hard to spot the blank spots in your own writing. What you skipped because it felt obvious is exactly what a reviewer catches first. Getting a third-party check on the seven elements and six questions one more time catches the parts you left out as "too obvious to write."