Building a multi-stage application form

A long application is not a long page. This guide covers stages, choosing field types deliberately, showing questions only when they apply, attaching resources, setting the window and capacity, and the preview pass before the public link goes out.

Before you start

• The questions, already agreed with whoever owns the call. Editing questions after the window opens is possible but it splits your data.
• An honest completion time. Fill the draft form yourself as an applicant; whatever it takes you, an applicant will take longer.
• The documents applicants must download: the call document, a budget template, a consent form, a format note for the pitch deck.
• The rules: eligibility, attachment size and format limits, the closing date and time zone, and whether there is a cap on total submissions.

Step 1: plan the stages

Stages exist for the applicant, not for you. Each one should be a single sitting — fifteen minutes or so — with a coherent subject, so an applicant can stop at a stage boundary and come back without losing their place. Drafts are saved on the server, so resuming works across devices and sittings.

A structure that holds up for a seed-fund call:

1. About the team — identity, institution, roles, contact
2. The idea — problem, solution, customer, differentiation
3. Technology and readiness — TRL, prototype status, intellectual property
4. Plan and budget — milestones, use of funds, timeline
5. Declarations and uploads — eligibility declarations, consent, pitch deck

Put the short, easy fields first. An applicant who has completed a stage is far more likely to finish than one who abandoned on the first hard question.

Step 2: choose field types

Eleven field types are available. Choosing the right one is the difference between data you can filter and 181 free-text answers you have to read.

Two rules worth keeping. Anything you will report on later must be a structured field — a TRL captured as a number gives you a readiness chart, the same thing inside a paragraph gives you nothing. And set a character limit on every long-text field; it is the most reliable way to keep reading time under control, and at 543 reads in a round every hundred words is measured in hours.

Mark a field mandatory only if you would genuinely reject an application without it. Everything else is a nudge.

Step 3: add conditions

A condition shows a field only when an earlier answer makes it relevant: show the incorporation number only when the team says it is registered; show the facilities question only when the sector is hardware; show the co-applicant block only when the team size is more than one.

The operators available are is, is not, is one of, has been answered, has not been answered, and the numeric comparisons greater than, greater than or equal to, less than and less than or equal to.

Conditions do the real work of keeping a ninety-field form short for any individual applicant. Three practices keep them maintainable:

• Condition on structured answers only. A condition on a single choice or a yes-or-no is stable; a condition on free text is not.
• Keep the chain one level deep. A field shown by a field that is itself conditional is almost impossible to test and produces applicants who cannot see a mandatory question.
• Never make a hidden field mandatory without checking. This is the most common form fault. The applicant sees a validation error against a field they cannot see, and they will email you about it.

Test each condition in both directions during the preview pass: answer one way and confirm the field appears, answer the other and confirm it disappears and stops being required.

Step 4: attach resources

Resources are documents attached to a stage and downloadable from it: the call document, the budget template, the consent form, the deck format note.

Attach each to the stage that needs it rather than collecting them all on the first page: an applicant reaching the budget stage should find the budget template there. Name files so the name is still useful in a downloads folder — "Seed-Fund-2026-Budget-Template.xlsx", not "template.xlsx" — and update the resource in place if it changes, so nobody works from the old one.

Step 5: set the window and capacity

1. Set the opening date and time and the closing date and time, with the time zone stated explicitly. Applicants in other time zones will read it literally.
2. Decide the capacity. A cap on total submissions closes registration when it is reached; leave it empty for an uncapped call, and say which it is in the call document.
3. Decide whether applicants may edit after submitting, and until when. Allowing edits until the window closes prevents most duplicate submissions.
4. Set attachment limits: maximum file size and accepted formats. State them in the field's help text, not only in the validation message.

Plan for the last six hours. A large share of submissions arrive on the final day, so keep that afternoon clear and have somebody watching the support address.

Step 6: version, then preview

Every published change to the form creates a new version, and earlier versions can be restored. Use that deliberately rather than as an accident recovery.

1. Make your edits, then publish them as a version with a short note about what changed.
2. If something is wrong after publishing, restore the previous version rather than editing back towards it by hand.
3. Once the window is open, treat the form as frozen. Where a change is unavoidable, make the smallest possible one — fixing a typo in help text is fine, adding a mandatory field halfway through a call is not, because applicants who submitted earlier never saw it.

Then preview the whole form as an applicant would see it:

• Every stage, on a laptop and on a phone
• Every condition, answered both ways
• One full pass saved as a draft, closed, and resumed in a different browser
• One complete submission, including a real file upload at the size limit
• The acknowledgement email, read on a phone

Step 7: publish the public link

The public link is stable and safe to print. Publish it on the institution's own page rather than sending it only by email, so that the authoritative copy is somewhere applicants can find it again.

Before sending it out, open it while signed out. A form that works for you and is invisible to the public is the failure mode of the last step, and it takes ten seconds to rule out.

Delete the test submission after checking it, and confirm the submission count reads zero before you announce.

Checklist before you publish

• Stages ordered easiest to hardest, each one a single sitting
• Every field using the narrowest type that fits the answer
• Character limits set on all long-text fields
• Mandatory limited to what would genuinely cause a rejection
• Conditions one level deep, tested in both directions, no hidden mandatory fields
• Resources attached to the stage that needs them, named usefully
• Window dates with an explicit time zone, capacity decided and documented
• Attachment size and format limits stated in the help text
• Edit-after-submission rule decided and published
• Form version published with a change note
• Full preview on laptop and phone, draft saved and resumed, one test submission made and removed
• Public link opened while signed out