Hi HN,
I’ve been building GrantFlow, an open-source drafting workflow engine for institutional grant proposals.
The problem: many NGOs and implementing organizations spend a huge amount of time/money translating solid program ideas into donor-specific, reviewable proposal artifacts before they can even get meaningful feedback internally.
A lot of that work is not “thinking through the intervention” — it’s reshaping the same idea into structured outputs (ToC, LogFrame, MEL framing), aligning language to donor expectations, and managing review cycles.
GrantFlow is my attempt to reduce that overhead.
It takes structured project inputs and produces donor-aligned draft artifacts through a stateful workflow with review checkpoints (human-in-the-loop), instead of a single “generate everything” prompt.
What it does today (MVP):
- Donor-aware drafting strategies (specialized + generic donor coverage)
- Human-in-the-loop checkpoints (pause / approve / resume)
- Exportable artifacts (.docx / .xlsx / ZIP)
- RAG-ready donor knowledge namespaces (ChromaDB)
- FastAPI API for integration into internal tools
- Optional API key auth
- Optional SQLite persistence for jobs + HITL checkpoints
Tech stack:
- FastAPI
- LangGraph
- Pydantic
- ChromaDB (with local/in-memory fallback)
- Python 3.11+
Recent work I finished before posting:
- hardened CI + shell checks
- public API response redaction
- typed response models for status endpoints
- sqlite-backed job/HITL stores + WAL/busy_timeout
- protected PDF ingest endpoint (`POST /ingest`)
- readiness endpoint (`GET /ready`)
Why I built it this way:
- proposal work is iterative and review-heavy
- compliance/rules matter, so workflow/state matters
- teams need checkpoints and auditability, not just raw text generation
Who I think this may be useful for:
- implementing organizations (e.g. firms managing donor-funded programs)
- NGOs and local partners
- civic-tech / govtech teams building internal proposal tooling
- consultants who standardize drafting workflows across donors
Happy to answer questions, especially around workflow design / HITL / donor strategy modeling.
- It’s an MVP and currently optimized for drafting workflow structure, not final donor submission formatting. - Donor coverage is mixed: some donors have specialized strategy behavior, others use shared generic logic with catalog aliases. - RAG ingestion is intentionally simple right now (PDF ingest + namespace isolation); deeper citation traceability is on the roadmap. - Multi-tenant auth/permissions is not implemented yet (API key is service-level).
reply