Architecture and rapid prototype | December 2025
If you manage proposals, every unsupported answer creates another question for a subject-matter expert. Scattered source material makes it harder to see whether a response meets the RFP and whether the company can stand behind it. This architecture and rapid-prototype exercise explored keeping requirements, source evidence, human edits and the final presentation connected.
Designing an evidence-linked RFP proposal prototype
The assessment did not require code. I prepared an architecture and discovery response, created a recorded walkthrough and shared a rapid web prototype on December 9, 2025. The prototype address in that message matches the application later recorded in the build inventory.
My contribution was the architecture response and rapid prototype creation. This began as an assessment exercise, not a documented production commission. The scenario's annual RFP volume and hours per proposal were supplied assumptions, not a measured customer baseline. Keeping that distinction matters when explaining what the work accomplished.
Start with how a proposal gets reviewed
My discovery approach began with proposal managers and subject-matter experts walking through actual RFPs: how they identify requirements, where reusable material comes from, which sections require specialist judgment and what an acceptable first version looks like. Those were proposed discovery activities, not completed customer interviews.
I wanted the existing proposal templates to shape the application. A system built around generic prose could still fail when asked to deliver the technical approach, past performance and other sections a team actually uses. I also called for an inventory of source repositories, access permissions and restrictions on sending content to an AI provider before committing to the implementation.
The first scope was deliberately bounded: document upload, structured requirements, a knowledge library, section-by-section generation, human editing and a fixed presentation template. Minimal HubSpot integration was in the requirements. Broader document connectors, fine-grained approvals, multilingual support and a rich template designer were outside the initial core or deferred. These were scope decisions, not a list of completed integrations.
Keep requirements, evidence and answers connected
The proposed data model separated the RFP's requirements from the response sections written against them. Reusable documents were broken into chunks with source-document and section information. A citation record would connect a statement in a response back to the chunk used to support it.
That relationship shaped the review interface: original requirement, editable answer and a source panel close enough together for a reviewer to inspect the basis of the text. A citation marker is useful only when it leads to the relevant evidence. It cannot establish that the source is current, that the response satisfies the requirement or that the model interpreted it correctly.
The retrieval design combined semantic matching with metadata such as document type, agency, contract type and date. This was intended to avoid pulling superficially similar but irrelevant boilerplate into a response. When context was missing, the model was instructed to identify the gap instead of inventing an answer. The PRD also called for warnings when retrieval did not find sufficiently relevant material. These were specified controls, not independently validated safeguards.
Give the backend ownership of the proposal lifecycle
The Supabase documentation on pgvector describes storing embeddings and vector similarity search in Postgres. That explains the proposed retrieval component; it does not prove citation accuracy or validate this prototype.
I proposed a React/Vite workspace over a backend that manages parsing, retrieval, generation and export. Long-running parsing and presentation jobs would run asynchronously. The interface could show progress while work continued, rather than holding a request open for every processing step.
The design split storage into relational proposal records, a vector index for retrieval and object storage for uploaded files and generated presentations. The PRD made that concrete with Supabase Auth, Postgres, pgvector and Storage, along with organization-scoped records and backend-only model calls. That is the proposed architecture, not an assertion that each control was verified in the hosted prototype.
A model gateway would keep Claude-specific calls separate from the proposal logic so a future model change would not require rewriting the whole process. I kept the central orchestration in the backend for control and observability. Automation tools could support notifications and webhooks at the edges, rather than own the sequence that creates the proposal.
The exported file is part of the acceptance test
The presentation design used a fixed template. Reviewed proposal sections would map into slides, the backend would store the resulting PPTX and the reviewer would receive a signed download link. Keeping one template made the first version easier to define and inspect.
The later build record describes a dashboard, requirements, editor, knowledge library and export work across twenty versions. It also records PowerPoint failures involving private storage and file-path authorization. A document that looks finished in the editor is still an incomplete handoff if the intended reviewer cannot download and open the right file.
The artifacts from this work include the architecture and discovery response, a detailed PRD, the rapid prototype and the walkthrough reference. Current generation, citation accuracy, organization isolation, connectors and presentation export have not been independently validated end to end. The PRD's proposed reduction in proposal effort remains a target. I am not reporting saved hours, a higher win rate or production adoption.
My evaluation proposal was to use a curated set of prior RFPs and proposals to check retrieval quality and unsupported claims. A useful next test would follow one permitted RFP through requirement extraction, cited text, human edits and the final presentation. It should include a requirement for which the knowledge library has no answer, because that is where the missing-context behavior matters.
Before implementing the knowledge library, enterprise search and RAG readiness helps examine source access, retrieval needs and governance.
Projected impact: a scenario to test, not a delivered result
All inputs and calculated amounts in this section are hypothetical sample assumptions, not customer measurements, industry benchmarks or a forecast for this project. They are chosen to make the budgeting arithmetic inspectable. No verified delivered ROI is established for this case.
This is a new hypothetical workload, not the assessment’s annual RFP volume, effort estimate or reduction target. Baseline minutes include the whole manual package. Assisted preparation is followed by eight hours of SME, citation and presentation review per package. The projected capacity depends on reliable retrieval and a working export, neither of which is established end to end for this prototype.
Hypothetical monthly inputs for a proposal team producing four comparable packages per month: 4 completed proposal packages; 2,400 total staff minutes each in the manual baseline; 1,200 to 1,440 assisted preparation minutes plus 480 minutes of human review and correction each. Add 4 hours per month for maintenance and exception oversight. Use $80 per hour as an assumed loaded labor value and $300 per month for incremental tools, hosting and usage. These operating allowances are sample budgets, not vendor quotes.
- Projected baseline effort
- 4 × 2,400 ÷ 60 = 160 staff hours per month.
- Projected assisted effort, including review
- 4 × (1,200 to 1,440 preparation minutes + 480 review minutes) ÷ 60 + 4 maintenance hours = 116 to 132 staff hours per month.
- Projected capacity released
- 160 baseline hours minus 116 to 132 assisted hours = 28 to 44 staff hours per month.
- Projected capacity value
- 28 to 44 hours × $80/hour = $2,240 to $3,520 per month in labor capacity value.
- Projected capacity value less operating spend
- $2,240 to $3,520 capacity value minus $300 incremental operating spend = $1,940 to $3,220 per month, before implementation costs.
This is recurring monthly modeled potential, not cash savings or additional revenue. Freed hours only become useful capacity if the team can redeploy them. Payroll does not fall merely because preparation takes less time. Any avoided overtime or outside-service expense would need separate evidence. The dollar balance compares capacity value with operating spend; it is not profit or a cash-flow return.
The range varies only the assumed assisted preparation time. It is not a confidence interval or a promise of typical results. The comparison requires the same completed work and acceptance quality, with review and correction included. Lower adoption, harder cases, failed outputs, added support or higher operating costs can reduce the benefit to zero or make it negative.
One-time implementation costs are unknown and excluded, including setup, integration, training and initial validation. Any required migration or hardware acquisition is also excluded and must be priced separately. With that incomplete investment cost basis, no ROI percentage or payback period is claimed. Do not annualize this sample month as a forecast without validating sustained volume, adoption and costs.
Evaluate your proposal-review workload
From requirement extraction through the downloaded presentation, human-reviewed workflow design should define what counts as an accepted proposal package.
Start with a sanitized RFP, authorized reusable content and an accepted presentation template. Test missing evidence, citation relevance and the downloaded file. A proposal that cannot be supported or exported is not an accepted output, regardless of how quickly text was generated.
Bring one permitted RFP and the final deliverable your reviewers expect. We can discuss a test that counts source checking, SME corrections and presentation repairs before making an investment decision.
