Designing an Application Form Founders Will Finish
Most incubator application forms are too long, ask for things nobody scores, and lose the best applicants at question fourteen. Here is a better one.
The form is a filter, and it filters the wrong way
Every incubator wants more good applications and fewer bad ones. So the form gets longer, on the theory that effort filters out the unserious.
It does filter. It just filters for patience and free time rather than quality. The founder juggling a job, a prototype and two other applications abandons a thirty-question form at question fourteen. The one with nothing else on completes it comfortably. You have selected for availability and called it rigour.
The useful filter is not length. It is asking a small number of questions that are hard to answer well without having actually done the work.
Ask only what you will score
Open your rubric. Open your form. Draw a line from each question to the criterion it feeds.
Anything with no line is a question you are asking for no reason. In most incubator forms that is a third of it - fields collected because a previous form had them, or because someone might want them one day.
Two things to do with the unmatched questions:
- Move it to post-selection if you genuinely need it. Bank details, registration certificates and detailed team CVs are onboarding data, not selection data. Collecting them from ninety applicants to use eight is wasted effort on both sides.
- Delete it if you cannot say what you would do with the answer.
The reverse check matters too: every rubric criterion needs at least one question feeding it. Panels routinely have to score "market" from a form that never asked about the market, so reviewers infer it from tone, which is exactly the inconsistency the rubric was meant to remove.
Use the right question type for the job
Mixing types deliberately makes a form both faster to complete and far easier to score:
| Type | Use it for | Why |
|---|---|---|
| Single choice | Stage, sector, incorporation status | Filterable, comparable, one tap |
| Multiple choice | What support they want | Reveals fit without free text |
| Short text | Company name, one-line description | Forces concision |
| Long text | The three or four questions that matter | Where judgement actually happens |
| Number | Team size, revenue, users | Comparable, sortable, no interpretation |
| Date | Incorporation, first revenue | Objective |
| File | Deck, prototype link, certificate | Optional at application stage |
| Yes/no | Eligibility gates | Screens before anyone reads |
The mistake to avoid is free text where a number would do. "Tell us about your traction" produces four paragraphs you cannot compare; "How many people used the product in the last 30 days?" produces a number you can sort.
Put the eligibility gates first
If there are hard requirements - incorporated in India, founded within a certain window, a particular sector - ask them as the first two or three questions, and say plainly that they are gates.
Two reasons. Someone who fails them stops after ninety seconds instead of forty minutes, which is a kindness. And your reviewers stop spending time on applications that were never eligible, which is where a surprising amount of panel time goes.
The four questions worth arguing about
Most of the form is mechanics. These four are where the signal is:
1. What problem are you solving, and for whom specifically? The word doing the work is specifically. "Small businesses in India" is a market size, not a customer. "Kirana stores in Tier-2 cities that already use a billing app" is a customer.
2. What exists today, and who has used it? Not "what will you build". What exists. The gap between the two is the most reliable single signal in an application.
3. What have you learned in the last three months that changed your plan? Very hard to fake, because it requires having had a plan and having tested it. Founders who have genuinely been working answer this easily. Founders who have been planning cannot.
4. What do you want from this programme? The fit question. An applicant who wants funding from a programme that offers mentoring and space is a mismatch you both want to find now. A vague answer here is informative: they applied because you were there, not because you fit.
Reduce the cost of the form itself
Small mechanics that measurably change completion:
- Save and resume. A serious founder will not finish in one sitting, and a form that loses their work loses them.
- Show progress. "Question 6 of 14" converts far better than an endless scroll.
- Say the word count you expect. "Two or three sentences" prevents both one-word answers and essays.
- Give the deadline and the decision date up front. Not knowing when they will hear is the most common complaint applicants have about incubators, and it costs you nothing to fix.
Reuse questions across programmes
If you run more than one programme, the same fifteen questions keep being rewritten slightly differently. That is a small annoyance for you and a real problem for reporting: two forms asking about team size in different words produce data that cannot be compared across cohorts.
A reusable question bank fixes it. Write the question once, use it in every programme, and every answer to it is comparable across every cohort you have ever run. That is the difference between having application data and having application archaeology.
After submission: give the pipeline real states
The form is half of it. The other half is what happens to an application afterwards, and the failure mode is a status field with three values - received, accepted, rejected - and everything interesting happening in email.
The states worth having are the ones that answer "what is this waiting on":
- Submitted, and eligibility checked
- Under review, and by whom
- Change requested, and what
- Documents requested, and which are outstanding
- Shortlisted, interview scheduled
- Accepted, waitlisted, or declined
- Withdrawn by the applicant
The two that pay for themselves immediately are change requested and documents requested. Without them, "we asked them for the incorporation certificate three weeks ago" lives in one person's sent folder, and nobody else can see what is outstanding.
The honest summary
A good application form is short, maps question-to-criterion, gates eligibility early, and asks four genuinely hard questions. It is not a test of endurance.
If you change one thing this round, delete every question you cannot draw a line from to your rubric. That single pass typically removes a third of the form and costs you nothing you were using.
Frequently asked questions
- How long should an incubator application form be?
- Short enough that a serious founder finishes it in one sitting - in practice twelve to eighteen questions. Every question past that costs you completions, and the applicants you lose are disproportionately the ones with options, because they are the ones who can afford to abandon it.
- Should we ask for a pitch deck or a form?
- A form, with the deck optional. A deck is written to persuade an investor and is not comparable across applicants, so scoring twenty of them fairly is nearly impossible. Structured answers to the same questions are what make a rubric work.
- What is the single most useful question to add?
- "What do you want from this programme?" It is the one question that predicts fit rather than quality, it cannot be prepared in advance from a template, and a vague answer is genuinely informative.
- Should applications be scored blind?
- Partly, and it is worth the effort. Hiding names, institutions and photographs during first-pass scoring reduces the pull of a familiar college or a known founder. Reveal identity at shortlist stage, when you need it for diligence and conflict checks.
