How to Write a Grant Application That Doesn't Get Rejected

Most rejected grant applications aren't rejected because the business wasn't a good fit for the program. They're rejected because of how the application was written — which is the part that's actually fixable.

Mistake #1: answering the question you wish they'd asked

Every narrative question on a grant application is trying to test something specific — usually one of: does this project fit our mandate, is this business capable of delivering it, and will the money make a real difference. A generic answer about how great your business is, without directly addressing what the question is actually testing, reads as evasive to a reviewer — even when it isn't meant to be.

Mistake #2: burying the specific number

Reviewers read a lot of applications. Vague language ("significant growth," "substantial impact") gets skimmed past. A specific number — jobs created, revenue increase, units produced, emissions reduced — anchors the reviewer's attention and gives them something concrete to cite when they're justifying your application to whoever approves the final decision.

Mistake #3: writing the narrative before understanding the evaluation criteria

Most programs publish (or will tell you if you ask) exactly how applications get scored — which criteria carry the most weight. Writing the strongest possible narrative against the wrong weighting is a waste of good writing. Read the evaluation criteria first, then write to it, not the other way around.

Mistake #4: treating the budget as an afterthought

A budget that doesn't map cleanly to the narrative is one of the fastest ways to trigger reviewer skepticism — if you say the project needs new equipment but the budget shows mostly consulting fees, that mismatch gets noticed. The budget should read like a direct translation of the story you just told, not a separate document that happens to be attached to it.

The underrated fix: read it as a stranger would

You know your business. The reviewer doesn't. Before submitting, have someone with zero context read the application and flag every place they had to guess what you meant. Those are exactly the spots a real reviewer will either misread or quietly mark down.