A grant concept note is a short pre-proposal that helps a funder decide whether to invite or encourage a full application. It usually summarizes the applicant, problem, proposed project, fit with the funder, requested amount, expected outcome, and evidence of readiness.
A concept note is a gate document. Its job is not to prove every detail of the project. Its job is to make the funder believe the opportunity is in scope, credible, and worth a longer review. That makes it different from a full proposal and different from a generic letter of intent.
For deeptech founders, a concept note should be compact but evidence-led. It should identify the technical gap, explain why the project is bounded, show the current evidence base, and describe the milestone the grant would unlock. A concept note that reads like a brochure usually fails because the funder cannot see what work will actually happen.
The example below uses the same heat-pump startup from the checklist hub. The structure works for many pre-proposal, EOI, and stage-one screening processes, but the exact sections should follow the funder instructions.
Use the example below as a working reference. The point is to show the level of specificity reviewers need: project context, evidence, owner, timing, and output. Adapt the fields, language, and level of detail to the official instructions for the specific grant.
Quick answer
A strong concept note makes one reviewer job easier: it turns a broad claim into something that can be checked. The exact format depends on the funder, but the artifact should state the purpose, show the relevant evidence, and connect to the rest of the application package. It should not sit apart from the budget, narrative, letters, work plan, or compliance documents.
- Make the asset specific to the project. Generic language is the fastest way to make a real grant application feel thin. Name the work, evidence, owner, timing, and output where the funder allows it.
- Connect it to the review criteria. The artifact should support feasibility, impact, team capability, cost reasonableness, or funder fit. If it does not help a reviewer score the project, tighten it.
- Keep it consistent with the rest of the package. Dates, amounts, milestones, partner roles, and claims should match the application form, technical narrative, budget, and letters.
- Use examples as structure, not copy. The examples below show shape and level of detail; real applications need funder-specific instructions and current evidence.
Example concept note skeleton
The following example follows Acme Thermal Systems, applying for pilot-validation support for a modular high-temperature heat pump. The details are deliberately concrete because founders need to see what the document looks like, not just read advice about it.
| Field | Example |
|---|---|
| Title | Pilot validation of a modular high-temperature heat pump for industrial drying |
| Applicant | Acme Thermal Systems Ltd, UK SME developing industrial heat hardware |
| Need | Industrial drying customers need lower-emission process heat without production downtime or full plant redesign. |
| Current evidence | Prototype v1 reached 230C in bench tests over 80 operating hours; two manufacturers have shared pilot-site requirements. |
| Proposed project | Build and validate prototype v2 under customer duty cycles, producing pilot data and deployment-readiness evidence. |
| Funding ask | GBP 420,000 grant toward a GBP 700,000 18-month project. |
| Expected outcome | Evidence package for paid demonstration, investor diligence, and manufacturing partner discussions. |
Concrete artifact block
This is the part most shallow articles skip. A useful guide should show the actual working object: a table, paragraph, outline, register, script, or package map that a founder can adapt. The artifact below is intentionally small, but it captures the level of specificity a reviewer needs.
| Section | Target length | What it must prove |
|---|---|---|
| Problem | 150 words | The need is specific, urgent, and in funder scope. |
| Solution | 200 words | The technology is credible and differentiated. |
| Applicant fit | 150 words | The team can execute the proposed work. |
| Project request | 150 words | The grant-funded work is bounded and realistic. |
| Expected outcome | 100 words | There is a concrete reason to invite a full proposal. |
How reviewers read it
Reviewers do not read a concept note in isolation. They compare it with the application form, proposal narrative, budget, milestones, letters, and evidence. If the artifact names a claim, the rest of the package should support it. If the artifact promises a deliverable, the work plan and budget should explain how it will be produced. This cross-check is where many applications lose trust.
| Reviewer check | What they want to see | What creates doubt |
|---|---|---|
| Fit | The asset answers a real funder requirement or scoring concern. | The asset looks added because it was available, not because it was requested. |
| Specificity | Names, amounts, dates, roles, tests, files, or milestones are concrete. | Broad claims with no basis or owner. |
| Consistency | The same facts appear across forms, narrative, budget, and attachments. | Different titles, dates, budget totals, or partner commitments. |
| Evidence | Important claims point to a report, letter, dataset, quote, or decision record. | The application asks reviewers to trust assertions. |
Weak vs strong example wording
The difference between weak and strong wording is usually not length. It is whether the sentence gives the reviewer something to evaluate. Strong wording names the project context, evidence, condition, or decision. Weak wording stays abstract.
| Version | Example | Why it works or fails |
|---|---|---|
| Weak | We are transforming industrial heat with a breakthrough platform for net-zero manufacturing. | Too broad and promotional. It does not define project scope or evidence. |
| Strong | This project validates thermal output, uptime, and installation requirements for a prototype heat-pump unit during a controlled customer-site pilot. | Specific, bounded, and reviewable. |
| Weak | Several customers are interested in our solution. | Unsupported. |
| Strong | Two manufacturers have provided process requirements and one has offered conditional pilot-site access if the grant is awarded. | Names the type of evidence and condition. |
How to build it without overclaiming
The safest process is to build the artifact from source facts, not from memory. Start with the official funder instructions. Pull the relevant facts from the company profile, grant brief, technical evidence, budget, and partner commitments. Draft the asset. Then reconcile it against every other part of the submission before upload.
- Open the official application instructions and mark whether the asset is required, conditional, optional, or not applicable.
- List the claims the asset needs to support. For each claim, identify the evidence source or owner.
- Draft the asset in the funder language, not the internal company language.
- Check consistency against the application form, budget, work plan, and narrative.
- Remove unsupported claims, stale facts, and unnecessary extra material before submission.
How funder context changes the asset
The same artifact can look different across NSF, NIH, EIC, Grants.gov, Horizon, defense, foundation, and private programs. The funder context changes page limits, scoring criteria, attachment rules, and acceptable evidence. Use the examples as patterns, then reconcile the final format with current funder instructions.
| Funder context | How to adapt | Example adjustment |
|---|---|---|
| US federal forms | Follow workspace, form, attachment, and agency instructions first. | Make sure form fields and PDF attachments use the same project title and dates. |
| NSF-style research proposal | Use proposal preparation rules, project summary logic, budget justification, and data plan requirements where relevant. | Connect project description, biosketches, budget, and facilities. |
| NIH-style biomedical application | Follow application-guide sections, format rules, human-subjects/animals triggers, and budget instructions. | Keep research strategy, biosketches, facilities, and letters aligned. |
| EIC or innovation-panel process | Show market, implementation, team, financials, pitch, and technical evidence. | Translate the artifact into a pitch-ready and diligence-ready format. |
| Foundation or private grant | Keep language accessible and impact-focused while preserving evidence. | Avoid excessive technical jargon unless expert review is expected. |
Where this fits in the application package
This asset should be connected to the rest of the submission package. Use the grant application documents checklist to decide whether it is required, then connect it to the grant proposal template, grant proposal example, budget justification, and any relevant letters, financials, or evidence pages. A complete package reads as one coherent project, not a stack of unrelated files.
- Related guide: grant application documents checklist.
- Related guide: grant letter of intent.
- Related guide: grant executive summary.
- Related guide: startup grant application process.
Filled mini example: concept note opening
Example opening: Acme Thermal Systems is developing a modular high-temperature heat-pump platform for industrial drying processes that currently rely on fossil-fuel heat. The proposed project will validate prototype v2 under customer-relevant duty cycles and produce the evidence needed for a paid demonstration. The project is a fit for this funding call because it addresses industrial decarbonization, advances a hardware technology beyond bench validation, and creates measurable pilot evidence within an 18-month scope.
The concept note should then move quickly from context to project. It should not spend a page on the company history. In this example, the next paragraph would state that prototype v1 has reached 230C in bench testing, that two manufacturers have shared operating requirements, and that one prospective pilot partner can provide site-planning data if the project is awarded. The funder can now see that the project is not starting from an untested idea, but also that the main deployment evidence remains to be created.
The final paragraph should make the request and outcome clear. Acme requests GBP 420,000 toward a GBP 700,000 project. By the end of the project, the team will deliver a bench validation report, pilot operating log, installation checklist, downtime analysis, and deployment-readiness memo. The concept note does not need every detail of the full proposal, but it must show enough scope, fit, and evidence logic to justify an invitation to apply.
| Concept note line | Example | Reason it matters |
|---|---|---|
| Funding ask | GBP 420,000 toward GBP 700,000 total project cost | Shows scale and co-funding expectation |
| Readiness proof | Prototype v1 reached 230C in bench testing | Shows the project is not speculative from zero |
| Outcome | Pilot data and deployment-readiness evidence | Shows why the full proposal is worth reviewing |
Common mistakes
Most mistakes come from either under-specificity or overclaiming. Under-specific assets force reviewers to guess. Overclaimed assets create credibility risk. The middle path is precise and honest: name what is known, what is not yet known, what the project will test, and what evidence the grant will create.
- Do not copy a generic template without changing the evidence. The structure can travel, but the claims must come from the actual project.
- Do not add unsupported certainty. If something is conditional on award, safety review, customer approval, or future test data, say so.
- Do not leave ownership vague. Reviewers trust artifacts more when owners, roles, and dependencies are clear.
- Do not let the asset contradict another file. Reconcile dates, titles, budget amounts, partner names, and milestones before submission.
- Do not make the artifact longer because it feels important. Make it more useful, not just larger.