A searchable RFP answer library your bid team drafts from

Build me a proposal answer library that my bid team works out of every time an RFP lands, so nobody rewrites an answer we already have. It is an internal app for bid managers, proposal writers and the sales leads who sign off on their work. The whole point is that every answer we put in front of a client is traceable back to a real proposal we submitted, with the outcome of that bid visible next to it.

The main screen is a searchable archive of every past proposal and questionnaire we have submitted. The documents themselves live as files in General Input Storage, and the archive pages through them with the List Objects operation under a proposals prefix. Each row shows the client name, the submission date, the sector and whether we won or lost, with a coloured outcome tag. Give me full text search across client and sector, filters for outcome and date range, and sorting by date. Every row has a preview or download action that mints a fresh link with the Presign Download operation at the moment of the click, because those links are short lived and must never be stored or reused. Keep an archive detail view where I can open one proposal, see its metadata, read the questions and answers extracted from it, and correct the client, sector or outcome if it was filed wrong.

Uploading a new RFP happens straight from the browser. The app asks for a link with the Presign Upload operation and the browser PUTs the file directly to that link, so a large PDF or DOCX never passes through a handler. The same upload path is used to seed the archive with past proposals, and there is a delete action on the archive detail view that uses the Delete Object operation and removes the matching rows. On upload the person tells me the client, the sector and, for a past proposal, the outcome and the submission date.

Once an RFP is uploaded, the app shows it broken into its individual questions. Each question sits next to the two or three closest answers we have used before, and each suggested answer shows the answer text, the source proposal it came from, whether that proposal was won or lost, and how old the answer is in months. Matching is on the wording of the question against the question bank, and I want the match to be visibly ranked rather than presented as a single right answer, because the writer is meant to choose. A writer can copy a suggestion into the working answer for that question, edit it, or write from scratch, and their working answers save as they go.

General Input Database holds everything that is not a file. Keep a proposals table with the client, sector, submission date, win or loss outcome and the storage key of the document in the store. Keep a questions table and an answers table so the question bank holds the question text, the answer text, the outcome tag inherited from its source proposal, and the storage key of the proposal that answer came from. Keep an rfps table for uploaded RFPs with the client, sector, storage key, upload date, status and the link to the drafted Google Doc, and an rfp_questions table holding each extracted question, the ids of the answers matched to it, and the working or drafted response. Files go in the store and only the object key goes in a row, never the document bytes.

Each RFP row has a Draft this response button that fires a background agent. The agent pulls the RFP document down using the Presign Download operation, reads it with the Mistral AI OCR operation so scanned and image based documents work as well as clean PDFs, splits the extracted text into individual questions and writes them to the rfp_questions table, matches each question against the answer bank in the database, and drafts a tailored answer per question rather than pasting the closest match verbatim. It then files the assembled draft with the Google Docs Create Document operation and fills the body with the Batch Update Document operation, laying it out as one heading per question followed by the drafted answer and a short provenance note naming the source proposal and its outcome. Finally it writes the document link back onto the RFP row so the archive shows it. While the agent runs, show progress on the row and let the person keep browsing the rest of the app.

The drafting agent needs to know who it is writing for, so it pulls deal context from HubSpot before it writes. Use the HubSpot Search Deals operation to find the open deal matching the client name on the RFP, and the Search Companies operation to pull that company's industry, size and any account notes. The sector and the deal size feed the drafting: a large enterprise bid in a regulated sector gets a different register from a small commercial one. Show the matched deal and company on the RFP detail view so a human can confirm the app latched onto the right record, and let them repoint it if the name match was wrong.

Two rules matter more than anything else and must be baked in everywhere. First, any answer sourced from a proposal older than twelve months is flagged stale wherever it appears, in the suggestion list and in the drafted document, so it is reviewed rather than pasted. The drafting agent treats a stale match as raw material to rewrite and leaves a visible review note against that question instead of quietly reusing old claims about headcount, certifications or product capability. Second, nothing is ever submitted from this app. There is no send action, no portal integration and no email step anywhere in it. The app only ever produces a draft in Google Docs that a named human owns, edits and submits themselves, and the interface should say so plainly at the point where the draft is handed over.

This solves a real and well documented problem: bid teams reuse old answers without verifying accuracy, which causes misalignment across proposals, reviewers spend hours sorting through outdated or duplicate content, and sales teams dig through endless files looking for answers they know exist somewhere. The visible win or loss on every source proposal and the stale flag on every old answer are the direct answers to those complaints, so keep both prominent rather than tucking them into a detail panel.