AI grant writing: a practical guide for small non-profits

AI grant writing is not a button that produces a finished application. In practice it means using a language model to read the funder's request for proposals, turn its requirements into a working outline, and draft each narrative section from facts your organisation has already recorded — its mission, the people it serves, past results and a real budget.

The value is in the first draft and the checking. Writers who used to stare at a blank page now start from a structured draft that already follows the funder's section order and word limits, and spend their time on the judgement work: the story, the evidence, the local detail no model can invent.

Automate: reading and summarising a long RFP, building the required section list, drafting boilerplate organisational background, restructuring a section to a word limit, checking that budget line items add up, and catching unanswered questions before submission.

Keep human: the statement of need and its local evidence, any claim about your outcomes, relationships with programme officers, the final read for tone, and every number that will be audited. If a model produces a statistic you cannot trace to a source, treat it as a placeholder, not a fact.

1. Record your organisation once. Mission, target demographics, annual budget, key programmes, verified past impact. Every future proposal reuses it instead of rewriting it.
2. Upload the funder's guidelines. Let the tool extract the required sections, questions, ordering and word limits rather than assuming a standard four-part structure.
3. Draft section by section. Each section should answer its own question. A draft that repeats the same project introduction four times reads like filler to a reviewer.
4. Build the budget as data, not prose. Line items, a requested amount and any matching contribution as separate figures, so the narrative and the spreadsheet can never disagree.
5. Audit before you submit. Check every requirement, every number and every unresolved placeholder. Then have a human read it end to end.

Most rejections at the first screen are procedural, not editorial: a missing section, a request above the funding ceiling, an ineligible expense, a narrative over the word limit. These are exactly the checks a computer does better than a tired human at 11pm.

A useful compliance check is arithmetical and evidence-based. It should confirm that line items sum to the requested amount, that a required match is calculated from the request rather than guessed, that no prohibited category appears, and that each stated requirement has actual proposal text behind it. Anything it cannot prove should be flagged for your confirmation rather than marked as passing.

• Submitting invented statistics a model produced to fill a gap.
• Leaving bracketed drafting notes such as "[Insert service area]" in the final file.
• Reusing a previous funder's language and its section structure.
• Letting the narrative and the budget state different totals.
• Generic, interchangeable prose that never names the community you serve.

Start with one live application and one funder document. Record your organisation's details, upload the guidelines, generate the draft, then spend your remaining time on the need statement and the evidence. If the result is stronger than what you would have written by hand at the deadline, keep going.