How to move your grant application form online

Start from the form you have

The starting point is often a Word document or PDF, guidance notes, an email inbox and a spreadsheet. Collect all four. The form shows what you ask, the guidance notes show what applicants find confusing, the inbox shows what goes wrong, and the spreadsheet shows what your team actually uses when deciding.

Then go through every question and ask why it is there. The GOV.UK Service Manual calls this a question protocol: for each question you should know why you need the answer, who must answer it and what you will do with it. IVAR's Open and Trusting commitments, which more than 140 grantmakers have signed, include ‘ask relevant questions’: collect only the information you need to make a funding decision.

Data protection law points the same way. Under the UK GDPR, personal data must be adequate, relevant and limited to what is necessary for your purpose. A shorter form is easier to fill in, easier to review and easier to defend.

Put eligibility questions first

Applicants who are not eligible should find out in the first minute, not after writing a project plan. The GOV.UK Service Manual gives the same advice for public services: ask eligibility questions first so that people who cannot use a service do not waste their time.

Keep this step short. Our demo for a fictional community trust asks four questions before anything else, so applicants know straight away whether the trust can fund them:

• What kind of organisation is applying, for example a CIO, a charitable company, a CIC or a parish council?
• Is it registered with the Charity Commission, OSCR or the Charity Commission for Northern Ireland?
• Will the project be delivered mainly in England or Wales?
• How much will it apply for, given a maximum grant of £25,000?

Required fields, checks and conditional questions

Online, a form can check answers while people type. The most useful checks for grant forms are simple ones:

• Required answers: the applicant cannot continue without them. Mark the few optional questions with ‘(optional)’ instead of putting asterisks on everything, as the GOV.UK Design System recommends.
• Formats: dates, email addresses, postcodes and registration numbers in a valid form.
• Amounts: the requested sum within your minimum and maximum, and budget lines that add up to the total.
• Dates: a project end date after the start date, and a start date after your decision date.
• Conditional questions: someone who mentions match funding is asked where it comes from; everyone else never sees that question.
• Clear error messages: say what is wrong and how to fix it, next to the field and in a summary at the top. The GOV.UK validation pattern is a good model outside government too.

Attachments

Ask only for documents you will actually read at this stage. Consider whether you need every document from every applicant, or only from those you shortlist. Each document you drop from the first stage saves applicants time and your team checking.

Online, each upload can be checked for file type and size, and a required document cannot be forgotten. Tell applicants which formats you accept and the maximum file size before they start, not when an upload fails.

Review page, submission and PDF copy

Before submitting, applicants should see all their answers on one page and be able to change any of them. The GOV.UK Design System calls this a check answers page. After submitting, they should get a confirmation and a PDF copy of what they sent, which also helps when they apply to several funders with similar text.

This step matters for accessibility too: WCAG 2.2 asks that submissions with legal or financial consequences can be checked, corrected or confirmed (success criterion 3.3.4).

Long forms: save and return

If your application takes more than one sitting, applicants will want to save it and come back. There are two ways to handle this: build save and return, by email link or user account, or make the form short enough to finish in one go, for example with a short first-stage application and a full application only for shortlisted projects.

Be clear about what your tool can do. In our own application engine the draft is kept during the browser session; saving by link or account is not built in, and we build it when a programme needs it.

How applications reach your team

Decide this before you design the form, because it determines which data you need and in what shape. A typical minimum is a list of incoming applications, a detail view of each one, a PDF copy and an export to a spreadsheet. If you assess in a panel, score applications or pay grants in instalments, you need either a grant management platform or a link from the form into the system you already use.

In our engine, the reviewer portal has a list of incoming applications, a detail view and a CSV export that opens in Excel. Assessment and scoring stay in your existing process.

Accessibility and data protection

Build to WCAG 2.2 level AA from the start rather than fixing a finished form. The W3C forms tutorial covers labels, instructions, validation and multi-page forms. Councils running grant schemes are covered by the public sector accessibility regulations. Charities are usually exempt, unless for example they are mostly financed by public funding or provide services aimed at disabled people. The Equality Act 2010 duty to make reasonable adjustments applies to service providers more widely.

Under the UK GDPR you remain the controller of applicants' data. If a supplier hosts the form, you need a written contract with the processor. If the data is stored outside the UK, check the transfer rules: for EEA countries, including Germany, the UK has adequacy regulations, so according to the ICO no transfer risk assessment is needed, although you should still make reasonable checks on the recipient. This is general information, not legal advice; take legal advice for your case.

What it costs: software, form builder or custom form

There are three common routes. A general form builder is quick to set up; check whether it handles your eligibility logic, budget checks and the way your team reviews applications. A grant management platform covers the whole grant cycle on an annual subscription. A custom online form covers the application and its intake and is paid for once per stage, plus hosting if the supplier runs it.

Some grant management platforms publish their prices. We checked these pages on 17 October 2026:

How a custom form is priced

We do not publish a price list for application forms. After a no-obligation intro call we quote a fixed price for each stage before any code is written, for example the concept with a clickable prototype, the form itself, and optionally the reviewer portal, integrations and hosting. You can test after each stage.

The price depends mainly on the number of steps and questions, how complex the eligibility and budget rules are, the number of languages, and whether data has to flow into an existing system. A form for one programme with one reviewer list is a different job from a portal for several programmes.

A sensible order of work

These steps apply whichever tool you choose:

1. 1Collect your current form, guidance notes and the spreadsheet your team uses.
2. 2Remove questions that do not inform a decision and move eligibility to the start.
3. 3Define checks, conditional questions and required documents.
4. 4Decide how applications reach your team and what happens to the data afterwards.
5. 5Build a clickable prototype and test it with two or three real applicants.
6. 6Launch for one funding round, collect feedback, then adjust.