Writing grant applications with AI

How the bot works

Nine steps. Reading the guidelines into a checklist, pulling the right library material, assembling the attachment set and checking the limits are ordinary code and cost almost nothing to run; the model is only asked to write your own material into the shape this funder asked for.

1. It reads the funder's own materials first. The notice, the guidelines, the application form, the portal's question list, the attachment instructions. What this funder asked for is the specification, not a general idea of what a grant application looks like.

2. Every requirement becomes a line somebody can check. Each question with its word or character limit, each attachment with its format, the eligibility questions, the signatures required, the deadline and the time zone it closes in. The checklist exists before any prose does.

3. It drafts each answer from your own library. The program description you already use, the approved budget, the logic model, last year's application that was funded, the audited financials, the board list. Nothing is drafted from general knowledge about organizations like yours.

4. Every claim names the document behind it. This sentence is that paragraph of the program description; this figure is that line of the approved budget; this outcome is that row of the report you filed. A reviewer can check an answer without rereading the whole file.

5. A number your library does not contain is a question, not a figure. Served counts, outcomes, percentages, match amounts, staff ratios. If the file does not have it, the draft carries an open question addressed to a person instead of a number that reads well. An invented figure in a narrative is a promise somebody has to keep later.

6. It writes in your words, not in grant-ese. Your style guide, your program names, the phrases your board uses and the ones you refuse. A draft that reads like a template is what this design is built against, which is why it starts from your own sentences rather than from an idea of what funders like.

7. It assembles the attachment set and names the gaps. The budget in the funder's format, the determination letter, the audit, the board roster, the letters of support — present, missing, or too old for this program. A missing letter is listed with who has to ask for it.

8. A person approves, and the people who sign are the ones who sign. The draft waits with the checklist, the open questions and the attachment gaps on top. Your reviewers edit and approve, and submission stays a human act in the funder's own portal. Nothing is filed by the bot.

9. It tells you what it could not answer. The questions with nothing in the library behind them, the numbers nobody has recorded, the attachments that do not exist yet, the eligibility question somebody has to settle. That list is the useful output in the first week, because it is the part of the application that was always going to be the hard part.

What you configure

It can be configured to run in any business. This is what that actually means — the list of things that are yours, not ours.

Your library

Which documents may be drafted from: program descriptions, funded applications, reports you filed, the logic model, the approved budget, the audit, the board roster. And which are out of bounds.

Your programs

What each program actually does, who it serves in the words you use, and which program a given funder's priorities map to.

Your numbers of record

Where an outcome figure may come from — the report you filed, the database export, the audited statement — and the rule that nothing else counts as a source for a number.

Your voice and your do-not-say list

The language your board approved, the words you refuse to use about the people you serve, and the claims you will not make about results.

Your funders and their formats

Each funder's question set, limits, attachment formats and portal quirks, so the draft arrives in the shape that funder asked for.

Your deadlines

The dates, the time zones, how far ahead a draft should exist, and who is told when an application is at risk of being late.

Your attachment set

The standing documents, which version is current, when each one expires, and who owns getting a new one.

Your reviewers and signers

Who edits, who approves a narrative, who approves a budget, and who signs. Nothing reaches a portal without them.

Your release switches

Which funders and question types may be drafted automatically when a notice appears, which wait for somebody to ask, and whether drafting is on at all.

Transparent, and configurable by you

The dark band below is what the system will not do. This is what you can see and change — and it is how we build everything, not something invented for this page.

You see what it did, and why

Every answer names the library document behind it, every open question says what is missing and who it is addressed to, and every draft records the checklist it was built from, the library version it read and who approved it. An application can be checked against your own file rather than taken on trust.

Versioned prompts you can tune yourself

The library, the numbers of record, the voice rules, the funder formats and the prompts behind the drafting are yours to tune. A change is a reviewable diff, replayed against applications you have already submitted so you can see what it would have written differently, and rolled back the same way.

A human in the loop wherever judgment actually matters

Reading the guidelines, building the checklist, drafting from the library and assembling the attachments are automatic. Deciding what to promise a funder, what a program will achieve, which numbers to put forward and whether to apply at all are a person's — that boundary is a property of the system, not a promise about how carefully we'll use it.

Every run logged, along with what it cost

One row per application: the guidelines it read, the checklist it produced, every answer with its sources, every open question, the attachment gaps, who edited, who approved, and what it refused to write — plus token usage and cost for that run.

It can be configured to run in any business. The library and the rules are yours: your programs, your approved budget, your numbers of record, your voice, your reviewers. The grant work on this page is one configuration of it, not the limit of it.

Works with your tools

This drafts from the files you already keep and writes into the documents your reviewers already use. We're not selling you a grants platform, and your library stays yours.

• Google Workspace
• Microsoft 365 and SharePoint
• A shared drive folder
• A grants or donor database
• QuickBooks Online
• A spreadsheet of deadlines
• Funder portals (read only)
• Scanned PDFs

Works well for

• Nonprofits — The applications, the reports and the newsletter can all land on one person, and the deadlines do not move.
• School districts — Program money arrives with required formats and a narrative that has to line up with last year's.
• Fire departments and municipal agencies — The same programs come round every year with the same questions and a new form to put them on.
• Arts and cultural organizations — Each funder wants the same work described for a different audience, in a different word count.
• Universities and research teams — The budget narrative, the biosketch and the data plan live in different files and the portal wants all of them.

How a rollout works

Nothing is submitted on day one, and nothing is sent to a funder. The first milestone is an application you have already filed, drafted again from your own library, so you can compare it answer by answer with the one you actually sent.

1. 01Discovery

   The quote call, then a working session. We go through the funders you apply to, where your program material and numbers of record live, which documents may be drafted from, your voice rules, your attachment set, who reviews and who signs, and what must never be drafted automatically. You get the library map, the rules and a written scope.

2. 02Dry run

   An application you have already submitted, drafted again. Nothing is filed. You compare the answers with what you sent and read the open-question list — and the open-question list is where the work is, because the numbers nobody has recorded are invisible until something asks for them.

3. 03Assisted mode

   Live on one funder. The bot produces the checklist and the draft, your development lead edits and approves, and submission stays in your hands. Who decides what you promise does not change.

4. 04Optional limited automation

   Optional, and narrower than it sounds. A short list of funders and question types you name, drafted automatically when a notice appears, still unsubmitted and still waiting on your reviewers, with every hard stop in force and the kill switch. Plenty of teams stop at step 03, and that's a good place to stop.

What we don't claim

• No numbers we haven't earned. No win rate, no applications-per-month figure, no hours-saved claim, no dollars-raised number. We have not written your applications. What a draft takes and what it costs come out of the dry run, and they will be your numbers.
• No customer claims on this page. No names, no case studies, no logos.
• A draft is not an application. The judgment about what your program will achieve, what you are willing to promise and whether this funder is the right one is the part that wins or loses, and it stays with your people. The bot handles the assembly around it.
• A draft that reads like a template is the risk. This design is built against it: it drafts from your own sentences and your own file rather than from a template of what funders are supposed to like, and your editing pass is part of the workflow rather than a formality.
• It cannot fix a program that is not documented. If the outcomes were never recorded and the budget was never approved in writing, there is nothing for the draft to cite and the open-question list will say so. Writing that material down is yours to do, and it is worth doing for the next funder as well.

Questions people ask

Can AI write a grant application?

Yes, as a first draft built from your own file. An agent can read the funder's guidelines into a requirement checklist, draft each answer from your program library with the source named, assemble the attachment list, and hand your reviewers a draft with every gap marked. What it will not do is invent an outcome number or submit anything.

Where does it get the content?

From your own library: program descriptions, applications that were funded, reports you filed, the approved budget, the audit, the board roster. Not from general knowledge about organizations like yours, and not from another applicant's narrative.

What happens when the funder asks for a number we don't have?

The draft carries an open question with the funder's exact wording, addressed to the person who would know. Nothing plausible is written in. A figure in a narrative becomes a commitment in a report later, which is why this one is a hard stop rather than a judgment call.

Will a funder be able to tell we used AI?

That is their call to make, and we make no claim about it. What we can say is that the design is built against the failure this kind of drafting invites - formulaic, nonspecific prose - by drafting from your own sentences and your own program detail, and by leaving your editing pass in the workflow rather than around it. Disclosure rules differ by funder and that decision is yours.

Does it submit the application?

No. No portal upload, no email to a program officer, no signature, no certification ticked. The draft and the checklist are handed to your people and filing stays a human act.

Can it handle the budget?

It can put your approved budget into the funder's format and check the arithmetic and the required categories against their instructions. It sets no figure of its own - a line with no approved source is held as a question, and your finance person owns the numbers.

Is it safe to put our files into this?

Access is scoped to what you point it at, each client's data is separated, retention is yours and nothing trains anything. Information identifying the people you serve is redacted before any model call where you ask for it, and what a funder is told about participants stays a decision your reviewers make.

Can it track our deadlines and reporting?

It can hold the application deadlines, formats and attachment expiry for the funders you configure, and tell you when something is at risk. Tracking the obligations in an award after it is made - the report dates, the conditions - is a different bot with its own page.

Is there a record of what it wrote and why?

Yes, per application: the guidelines it read, the checklist, every answer with the library documents behind it, every open question, the attachment gaps, who edited and approved, and what it refused to write - plus the token usage and cost for that run.