Problem
Answering an RFP is mostly searching, not writing. Teams hunt through past proposals for the right facts, and a single unsupported claim in a submission creates commercial and legal risk.
Research & analysis
I broke the response process into its real steps: read the RFP, pull out the requirements, find where past proposals already answered them, then draft. The time goes into the finding. The risk sits in the drafting, where fluent text can make a claim that no document supports.
That changed the goal of the product:
- Traceability over speed. Every drafted claim must cite a literal excerpt from an uploaded file. If no excerpt supports it, the tool shows a gap instead of writing a plausible answer.
- Uploaded documents are untrusted input. An RFP or past proposal can contain text that looks like instructions to the AI, so uploaded content has to be isolated from the model's instructions.
- Some answers always need a person. Pricing, legal promises, security and compliance claims, dates and customer names are flagged for human verification, however good the draft looks.
Solution
- Requirement extraction from the uploaded RFP or security questionnaire.
- Matching each requirement against 2–5 past winning proposals.
- Cited drafting: each answer carries literal-excerpt citations, and unsupported claims are converted into explicit gaps.
- Untrusted-content isolation: the AI prompts treat uploaded documents as data and ignore any instructions inside them.
- Word export of the cited draft for human review and editing.
Build
A Next.js App Router app running a 4-step pipeline: extract requirements from the uploaded RFP, match them against past-proposal text, draft a response with Anthropic's API, then format the draft into a Word document. Job state and progress live in an in-process store, and evidence guards reject any AI-returned quote or citation that isn't a literal excerpt from an uploaded file, converting the rest into explicit gaps. Authentication uses signed, expiring, HTTP-only session cookies gated by a production password.
Built with AI-assisted development; I owned the requirements, the review boundary and the test plan. 12 automated tests cover auth tokens, rate limits, same-origin checks, upload policy, and the evidence/citation guards.
Result
A working local build with 12 automated tests covering security and the evidence guards. The drafting pipeline has not yet been validated with a live model run or tested on a real RFP, so answer quality, cost and time saved are unknown, and no customer outcome is claimed. Current status: pilot candidate.
Next step: one end-to-end run on a realistic synthetic RFP, measuring how many answers are correctly cited and how many become gaps, before any pilot outreach.
What I learned
The value of an AI drafting tool sits in what it is not allowed to do. Defining the rules — no invented citations, no following instructions hidden in documents — took more thought than the drafting step itself.
A visible gap beats a confident guess. An explicit "no supporting evidence" tells the reviewer exactly where to spend their time.
Tests prove the guardrails, not the quality. Automated tests show the security and evidence rules work. Only a live run on a real document can show whether the drafts are good, which is why that run is the next step rather than a footnote.