Preparing a Fund Application

What Is the Problem?

Three patterns repeat in rejected applications.

The problem is not defined

The file describes the technology, not the problem it solves. “We will analyse with AI” is not a problem definition. Who cannot do which job, and why, has not been written. When the problem stays invisible, so does the value of the solution.

Team and project do not match

The project described is large; the team is small. Or the reverse. This is one of the first things an evaluator checks: can this team do this work? If the file does not answer, the risk looks high. A small team writing a small project is fine. A small team writing a giant one is not.

The output cannot be measured

What happens at the end is vague. “A model will be developed” is not an output. How accurate will it be, which job will it speed up, who will use it? Without these, success stays undefined. And undefined success reads as risk at the evaluation table.

Why Does It Happen?

Three reasons.

The file gets written in the last week

The call is announced, the file gets rushed. A rushed file is heavy on technology description and thin on problem definition. Because problem definition requires thinking. Technology description is copy-paste.

The application gets written before the project

The correct order runs backwards. The fund is spotted first, then a project gets designed to fit it. Such projects look awkward even on paper, because they did not grow out of a real business need.

The evaluator’s perspective is ignored

The file speaks to itself. But the reader is moving through hundreds of applications. If they cannot tell what you want to do in the first paragraph, they will not read the rest carefully. That first paragraph deserves the most effort in the file.

How Is It Done?

The file has five parts. The order matters.

Step 1: the problem and solution sentence

The first paragraph does one job: explaining what you do. This template suffices. “Today [who] does [which job] with [which limitation]. We will improve this by [how much] using [which data] and [which method].” Do not move on until this sentence stands. If it cannot be built, what is missing is not the file but the project.

Step 2: the evidence layer

Every claim needs evidence behind it. Is there data, and where does it sit? Has the method been tried, is there a small trial result? Is there customer interest, who did you speak to? An unevidenced claim is the file’s weakest point. A small pilot result beats pages of promises.

Step 3: team, budget and calendar

The three get written together. Who does what, how much time they give, how much goes to which line. Eligible expense categories are broadly defined in the plan: personnel, cloud costs, data acquisition, labelling, model operations. Build the budget on those lines. An invented line gets noticed at first review.

How Long, Where to Start?

Clear arithmetic, a short first step.

A good file takes two weeks

Not in one sitting, but in parts. The problem sentence takes a day, gathering evidence a few days, budget and calendar a day, writing and review a few more. Evaluation then runs months. Write that into your cash plan; the work must stand on its own feet until the money arrives.

Rejection is also an output

The file you prepared stays. The problem sentence, evidence layer and budget skeleton are durable. The same file works at other doors too: vouchers, credits, pilot calls. Written once, it opens several doors.

First step: write the sentence, gather the evidence

Write the problem and solution sentence today; it takes fifteen minutes. Then list your evidence: what data we hold, what trial was run, who showed interest. Third, decide which rung you are applying to. On the funding ladder, the wrong rung eliminates even a good project.

The Common Mistake

Three traps are common.

Technology first, problem second

If your first page explains which model you will use, the order is inverted. The evaluator wants to understand the problem first, then the solution.

Promising everything

A broad scope is assumed to look strong. The opposite happens. A narrow, deep project beats a wide, shallow one. Solving one problem fully beats half-solving five.

Maxing the budget and ignoring the investor

Asking for whatever the ceiling allows is a common reflex. But an unjustified budget casts doubt on the project’s seriousness. Ask for what you need and justify every line. The second omission in the same file is the investor side. The Growth Fund aims to draw private capital alongside public money. A project with investor interest moves ahead. Running both processes in parallel makes each easier.

Frequently Asked Questions