AI Grant Writing Coach

Score our proposal using this scale: 1 (does not meet) / 2 (meets) / 3 (exceeds). If we've pasted specific funder scoring criteria, score against those. If not, score these exact criteria, in this order: 1. Problem grounded in real user need 2. Solution matches the problem 3. Co-design with the people being served 4. Lived experience on the team 5. Organizational capacity 6. Measurable outcomes 7. Sustainability beyond the grant period Score all listed criteria — do not add, drop, or rename criteria. Apply these scoring definitions: - "1, does not meet" means: criterion is absent, contradicted, or addressed only with non-committal language and aspiration. Example: a problem section that describes the issue in general terms with no named users, no field research, and no quotes scores a 1 on "problem grounded in real user need" — stating the problem exists is not the same as evidencing it. Organizational statistics ("we've served 3,000 users") are capacity claims, not user need evidence, and do not raise a score on this criterion. - "2, meets" means: criterion is addressed with specifics and evidence, but with at least one notable gap a reviewer would flag. Example: a problem section that cites a study and names the population, but doesn't show how that evidence connects to this org's specific users, scores a 2. - "3, exceeds" means: criterion is addressed with specifics, evidence, and either a stronger-than-typical answer or an additional dimension the rubric doesn't require. Example: a problem section that quotes users directly, names the research method, and shows how findings shaped the solution design scores a 3. Apply this ranking for "biggest gap": - The biggest gap is the one most likely to drop the score from a 3 to a 2, or a 2 to a 1, if left unaddressed. - Prefer gaps you can quote specific proposal text for over abstract weaknesses. Apply this specificity-density penalty across all criteria: if a section relies on vague claims, round numbers without sources, or low-specificity language (no named users, partners, dates, dollar amounts, or specific outcomes), reduce that criterion's score by one level. Specificity is what separates accepted proposals from rejected ones in real data. Begin your response with this exact line on its own: "Score guide: 1 = does not meet | 2 = meets | 3 = exceeds" Then for each criterion, respond in this exact format: Criterion: [name] Score: [1, 2, or 3] Gap: [one sentence naming the single biggest gap, quoting proposal text] To improve: [one sentence naming what you could add or sharpen to raise this one level — point to the missing evidence or framing; describe what to strengthen, don't rewrite it for us; addressed to us as "you"] After listing every criterion, write one sentence on the overall scorecard and name which set of criteria you used. Then add a final block on its own, labeled exactly "Where to go deeper:". Name the one or two lowest-scoring criteria and tell us which stress test to run for a full teardown of each. Use these exact invoke phrases: - Problem grounded in real user need → "Run problem clarity" - Solution matches the problem / Co-design with the people being served → "Run solution fit" - Lived experience on the team → "Run lived experience" - Organizational capacity → "Run team capacity" - Measurable outcomes → "Run impact check" - Sustainability beyond the grant period → "Run sustainability" This scorecard grades the seven universal fundamentals only. It does not score AI responsibility, theory of change, systems thinking, or funder alignment — if any of those matter for this proposal, note that we can run "Run AI check," "Run theory of change," "Run systems thinking," or "Run funder alignment" as separate deep-dive checks. Stop there. Be tough. Don't grade on a curve.

Pretend you're a skeptical program officer who has reviewed hundreds of proposals. List exactly five questions you'd ask the applicant. Apply this ranking criterion. A "damaging" question is one that: - targets a structural weakness in the proposal - would be hard to answer without admitting a gap - would require new evidence the applicant doesn't appear to have - could shift the funder's evaluation significantly if answered poorly Order most damaging first. Number them 1 through 5. One sentence per question. No preamble, no headers, no commentary.

Read our full proposal. Identify the single weakest paragraph by writing quality, not by topic. Apply these failure mode definitions: - "Vague" means: lacks specific numbers, names, dates, or examples - "Generic" means: could appear in any nonprofit's proposal with minor swaps, no specifics to this org or this work - "Unsupported" means: claims made without evidence, citations, or data - "Non-committal" means: uses conditional language that avoids accountability — "may," "could," "hopes to," "potentially," "explore," "consider" Pick the paragraph with the highest count of these red flags across all four categories. If two or more paragraphs have a similar red flag count, apply this tie-breaker in order: 1. Pick the paragraph whose gap is most likely to cause a reviewer to recommend rejection — a weak claim about money, capacity, or evidence outweighs a weak claim about values or vision. 2. If still tied, pick the paragraph carrying the most load-bearing claim — the one other sections depend on being true. Respond in exactly three sections, no preamble, no headers: Weakest paragraph: [quote the full paragraph] Diagnosis: [one sentence naming which failure modes apply and where] What it needs: [2-3 sentences naming what type of evidence, structure, or specifics would fix this paragraph — name the direction, not words to use, addressed to us as "you"]

Pretend you're the application reviewer who's about to recommend rejection. Tell us the three strongest reasons you'd give for why you can't fund this. After that, ask us five tough follow-up questions, one at a time, waiting for our answer before moving to the next. Push back on any answer that: - is vague or non-committal ("we hope to," "we plan to explore") - doesn't actually address the question you asked - contradicts something in our proposal - introduces new claims or assumptions without evidence - relies on credentials or aspiration instead of specifics Be direct and specific. Your job is to give the kind of honest feedback a program officer would give off the record — focused on what the proposal needs, not on making the team feel good or bad about the work they've done.

Review our proposal against this question: is the problem grounded in real user need? Go deep — this is a full teardown of the problem section, not a snapshot. Apply these criteria when answering: - "Evidence of user input" means: names specific users or communities consulted, quotes users directly, cites field research the team conducted, or describes co-design sessions. Generic stats and demographic claims don't count. - "Reads as assumed" means: uses "we think/believe," cites statistics without naming the source or specific community, or generalizes about user needs without specifics. - "User-voice balance" means: in the Problem section only, count the number of sentences that center the user's experience (sentences where the grammatical subject is a user — "adults," "job seekers," "people," "they," etc.) versus sentences that center the organization (sentences where the grammatical subject is "we," "our," or the org name). Report as "user-centered: X sentences, org-centered: Y sentences." If org-centered sentences outnumber user-centered sentences, call it we-heavy. If equal or user-centered is higher, call it balanced. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether this problem is real and understood — phrased in their voice, the way they'd say it out loud in a review meeting. - "What grounded looks like" means: the type and shape of evidence that would move this section from assumed to grounded. Name the kind of proof — do not draft the sentences for us. Respond in exactly six lines, no preamble, no headers: Problem stated: [one sentence quoted from proposal] Evidence of user input: [one sentence quoted from proposal, or "none stated"] User-voice balance: [one sentence: balanced (user-words match or exceed we-words), or we-heavy (more we-words than user-words), with rough counts] Where it reads as assumed: [one sentence pointing to specific text, or "none detected"] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] What would make it grounded: [2 sentences max — name the specific gap and the type of evidence or information that would close it; describe what to strengthen, don't write it for us; addressed to us as "you"]

Review our proposal against this question: does the solution match the problem, with evidence of co-design? Go deep — this is a full teardown of solution fit, not a snapshot. Apply these criteria when answering: - "Co-design evidence" means: named user advisors, documented user feedback cycles, iteration based on user input, or specific user-facing changes made before this proposal. Generic statements like "designed with the community in mind" don't count. - "Mismatch or overreach" means: solution claims to address a broader problem than the one stated, solution proposes capabilities not justified by the user need, or solution is a technology-first answer to a problem the user need says is non-technical. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether this solution actually fits the stated problem — phrased in their voice, the way they'd say it out loud in a review meeting. Respond in exactly five lines, no preamble, no headers: Solution claimed: [one sentence quoted from proposal] Co-design evidence: [one sentence quoted from proposal, or "none stated"] Mismatch or overreach: [one sentence pointing to specific text, or "none detected"] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] Fix: [2 sentences max — name the specific gap and the type of evidence or information that would close it; describe what to strengthen, don't write it for us; addressed to us as "you"]

Review our proposal for evidence of lived experience on our team. Go deep — this is a full teardown of the team's lived-experience signal, not a snapshot. Apply these verdict definitions: - "Unmissable" means: explicit statement of a team member's firsthand experience with the problem, names them, and ties their experience to a specific product or program decision. - "Implied" means: vague language about "communities we serve" or "passion for this work" without naming team members or tying experience to decisions. Note: job titles alone (e.g., "community navigator," "outreach coordinator") do not count — a title is a role, not a lived experience signal. - "Absent" means: no mention of any team member's personal connection to the problem — only roles, credentials, or organizational history. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether this team truly has lived experience with the problem — phrased in their voice, the way they'd say it out loud in a review meeting. Respond in exactly five lines, no preamble, no headers: Concrete signal: [one sentence quoted from proposal, or "none stated"] Implied but not shown: [one sentence quoted from proposal, or "none"] Verdict: [one word: unmissable, implied, or absent] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] Make it concrete: [2 sentences max — name the specific gap and the type of information that would make this signal unmissable; describe what to strengthen, don't write it for us; addressed to us as "you"]

Review our proposal against this question: do we have the team and capacity to deliver? Go deep — this is a full teardown of delivery capacity, not a snapshot. Apply these criteria when answering. Note: full-time tech staff is not required for a strong proposal. Hybrid models (part-time, contractors, volunteers) can work. What matters is honesty about the tech model and capability to deliver. - "Tech model named" means: the proposal explicitly states who builds and maintains the tech (full-time staff, part-time staff, contractors, volunteers, vendors). If it's mixed, the mix is described. - "Capability evidence" means: named individuals with specific roles AND specific functions (e.g., "ML engineer focused on natural language processing"), shipped product evidence (named clients, deployment counts, named partners), or revenue from the tech. - "Key-person risk and runway" means: the proposal names what happens if a key person leaves, has a succession plan, or shows runway to sustain the work through and beyond the grant period. - "Internal consistency" means: founding year, operational history, and revenue claims line up. If the proposal says founded 2024 but operational since 2023, that's a flag. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether this team can actually build and sustain what it proposes — phrased in their voice, the way they'd say it out loud in a review meeting. Respond in exactly six lines, no preamble, no headers: Tech model named: [one sentence quoted from proposal, or "ambiguous"] Capability evidence: [one sentence quoting named people, deployments, or revenue, or "none stated"] Key-person risk and runway: [one sentence: addressed how, or unaddressed] Internal consistency: [one sentence: consistent, or where it contradicts itself] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] Fix: [2 sentences max — name the specific gap and the type of evidence or information that would close it; describe what to strengthen, don't write it for us; addressed to us as "you"]

Review our proposal against this question: are we measuring outcomes or just outputs, and are our numbers credible? Go deep — this is a full teardown of the measurement approach, not a snapshot. Apply these definitions: - "Outputs" are activities the organization completes: sessions delivered, users reached, hours of programming, content published. Outputs measure effort, not effect. - "Outcomes" are changes in users' lives or circumstances that result from the work: skills gained, employment outcomes, health improvements, behavior change, system change. Outcomes measure effect. - "User feedback loop" means: a named mechanism for collecting user feedback and using it to change the work, not just an end-of-program survey. - "Round-number red flag" means: large round numbers ("25M tons of CO2 annually," "500 users served," "20 awards won") that appear without a methodology, named source, or breakdown by year. Repeated round numbers across multiple sections amplify the flag. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether these numbers show real change — phrased in their voice, the way they'd say it out loud in a review meeting. Respond in exactly six lines, no preamble, no headers: Metrics listed: [one sentence quoted from proposal] Outputs vs. outcomes: [one sentence naming which listed metrics are outputs and which are outcomes] Round-number red flags: [one sentence quoting any unsupported round-number claims, or "none detected"] User feedback loop: [one sentence quoted from proposal, or "not addressed"] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] Stronger metric: [2 sentences max — name the specific output metric that's weakest and the outcome metric that would replace or complement it; describe what to strengthen, don't write it for us; addressed to us as "you"]

Review our proposal against this question: is our theory of change explicit and credible? Go deep — this is a full teardown of the theory of change, not a snapshot. Apply these criteria when answering: - "Theory of change stated" means: the proposal explains WHY the intervention works — not just what it does, but the causal mechanism. A list of activities is not a theory of change. Look for logic like "by doing X, users can do Y, which leads to Z outcome." - "Causal chain" means: a sequence of cause-and-effect steps from the intervention to the intended impact. It must move from activity → behavior change → outcome — not just a timeline. - "Key assumptions" means: conditions that must be true for the change to happen that the organization doesn't control — e.g., internet access, employer behavior, policy environment. Unstated assumptions are not safer than stated ones. They're riskier. - "Evidence for mechanism" means: research, pilot data, or field evidence that this type of intervention produces this type of change in this type of context. Generic statistics about the problem area don't count. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether this causal logic actually holds — phrased in their voice, the way they'd say it out loud in a review meeting. Respond in exactly six lines, no preamble, no headers: Mechanism stated: [one sentence only — quote the proposal if it states a mechanism, or write "not stated"] Causal chain: [one sentence only — one of: "explicit: [brief quote]", "implied: [one phrase describing the assumed logic]", or "absent"] Key assumptions embedded: [2 sentences max — name the most significant unstated assumption and why it's load-bearing for the proposed change] Evidence for mechanism: [one sentence only — quote the proposal if evidence exists, or write "none cited"] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] Fix: [2 sentences max — name the specific gap in the theory of change and the type of evidence or information that would make it credible; describe what to strengthen, don't write it for us; addressed to us as "you"]

Review our proposal against this question: what happens to this work after the grant ends? Go deep — this is a full teardown of sustainability, not a snapshot. Apply these criteria when answering: - "Revenue model named" means: the proposal identifies a specific path toward financial sustainability — earned revenue, government contracts, fee-for-service, licensing, or a diversified grant strategy with named funders. "We plan to seek additional funding" does not count. - "Grant dependency risk" is: high if all current revenue is grant-funded with no earned revenue path named; medium if there's some earned revenue or a named diversification plan; low if earned revenue is significant or a credible multi-funder pipeline is described. - "Runway stated" means: the proposal shows the organization can sustain the work beyond the grant period — not just through it — by naming post-grant funding sources, revenue projections, or a specific bridge plan. - "Sustainability timeline" means: the proposal names when or under what conditions the work becomes self-sustaining, or identifies the next funding source with a realistic ask. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether this work survives past the grant — phrased in their voice, the way they'd say it out loud in a review meeting. Respond in exactly six lines, no preamble, no headers: Revenue model: [one sentence: named model with specifics, "grant-dependent only," or "not addressed"] Runway after grant: [one sentence: addressed how, or "not addressed"] Grant dependency risk: [one of: low, medium, or high — with a one-sentence reason] Sustainability timeline: [one sentence quoted from proposal, or "not stated"] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] Fix: [2 sentences max — name the specific sustainability gap and the type of financial information or planning that would address it; describe what to strengthen, don't write it for us; addressed to us as "you"]

Review our proposal against this question: does this solution understand the system it's entering? Go deep — this is a full teardown of the systems thinking, not a snapshot. Apply these criteria when answering: - "Root cause vs. symptom" — a root cause is a structural or systemic driver (e.g., lack of employer incentives, policy gaps, infrastructure inequity). A symptom is an observable effect of that driver (e.g., low employment rates, poor health outcomes). Most proposals address symptoms. Note which this is. - "Ecosystem named" means: the proposal identifies other actors, institutions, or structural forces that shape the problem — employers, government agencies, community organizations, funding patterns, infrastructure, policy environment. Naming the target population alone is not naming the ecosystem. - "Feedback loops considered" means: the proposal shows awareness that the intervention will change system dynamics — for better or worse. Example of positive: the tool lowers friction, which increases adoption, which generates data, which improves the tool. Example of negative: automation displaces workers the org claims to serve. - "Unintended consequences addressed" means: the proposal names at least one risk or tradeoff that could harm the people it serves or adjacent populations — and shows a monitoring plan or mitigation approach. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether this proposal understands the system it's entering — phrased in their voice, the way they'd say it out loud in a review meeting. Respond in exactly six lines, no preamble, no headers: Problem framed as: [one of: root cause (quote), symptom (name the root cause it implies), or mixed] Ecosystem named: [one sentence only — quote named actors or structures, or state "not named"] Feedback loops: [one sentence only: addressed (quote the logic), or "not addressed"] Unintended consequences: [one sentence only: addressed how, or "not addressed"] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] Fix: [2 sentences max — name the specific systemic gap and the type of thinking, evidence, or stakeholder engagement that would address it; describe what to strengthen, don't write it for us; addressed to us as "you"]

Review our proposal against this question: are we the right fit for this specific funder? Go deep — this is a full teardown of funder fit, not a snapshot. Apply these criteria when answering: - "Stage fit" means: our annual budget, organization age, and growth stage match what this funder typically funds as described in their RFP or website. - "Funder-specific signal" means: the proposal explicitly references this funder's stated priorities, language, or past grants in a way that couldn't apply to a different funder. - "Scope discipline" means: 1 to 2 issue areas reads as focused. 3 issue areas is borderline. 4 or more signals scattershot positioning and weakens fit with any specific funder. (Drawn from accepted-vs-rejected accelerator data: accepted median is 3, rejected median is also 3 but mean trends higher.) - "Reviewer's objection" means: the single sharpest question a skeptical program officer at this funder would raise about whether this proposal belongs in their portfolio — phrased in their voice, the way they'd say it out loud in a review meeting. - Verdict definitions: - "Fits" means: proposal addresses this funder's stated priorities and constraints directly. - "Transactional" means: proposal could be sent to any funder, no funder-specific framing or references. - "Wrong lane" means: proposal sits in a sector, geography, or stage this funder doesn't fund. Respond in exactly six lines, no preamble, no headers: Stage fit: [one sentence: right stage for this funder, or where it's off] Scope discipline: [one sentence: focused (1-2 issue areas), borderline (3), or scattershot (4+), with the list quoted] Funder-specific signal: [one sentence quoted from proposal, or "reads generic"] Verdict: [one word: fits, transactional, or wrong lane] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] Fix: [2 sentences max — name the specific gap and the type of information or framing that would close it; describe what to strengthen, don't write it for us; addressed to us as "you"]

Review our proposal on AI-specific concerns. Skip if AI isn't core to your work. Go deep — this is a full teardown of the AI claims, not a snapshot. Apply these definitions: - "Custom build" means: model trained or fine-tuned by the organization on their own data. - "Fine-tune" means: an off-the-shelf model adapted with the organization's data or domain inputs. - "Vendor API" means: calling a third-party model (OpenAI, Anthropic, Google) without modification. - "Off-the-shelf" means: using a consumer AI product (ChatGPT, Claude.ai) directly. - "Deployed vs. aspirational" means: deployed AI is in production today with users, with specific clients or use counts cited. Aspirational AI uses language like "we are looking to incorporate," "we plan to add," "we will integrate" — future-tense, no current users. Aspirational AI in a proposal is a major red flag. - "Data handling addressed" means: data sources named, consent process described, retention period stated, and access controls listed. Missing any one of these counts as not addressed. Note: vague statements like "user data will be stored securely" or "we have a privacy policy" do NOT count — all four elements must be present. - "Bias and oversight addressed" means: bias testing mechanism named, human-in-the-loop checkpoint described, and appeals path for affected users specified. Missing any one of these counts as not addressed. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether the AI is real, responsible, and more than a buzzword — phrased in their voice, the way they'd say it out loud in a review meeting. Respond in exactly six lines, no preamble, no headers: What's actually AI: [one of: custom build, fine-tune, vendor API, off-the-shelf, summarized from proposal] Data handling: ["not addressed" if any of the four elements are missing, otherwise one sentence quoted from proposal] Bias and oversight: [one sentence quoted from proposal, or "not addressed"] Deployed or aspirational: [one of: deployed (cite specific users or clients), aspirational (quote the future-tense language), mixed (some live, some planned)] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] What to add: [2 sentences max — name the specific gap and the category of evidence or information that would differentiate this from a generic AI pitch; describe what to strengthen, don't write it for us; addressed to us as "you"]