Recurring proposal work loses too many hours to reassembly.
Every proposal or quote a business writes routinely re-derives the same parts: the company story, the past work, the method, the structure the reader expects. I automated that assembly for a client, and the same pattern applies to any business that writes proposals, quotes, or technical reports on a deadline.
18 modules, 5,647 lines of code, 25 unit tests. Built and delivered for a client's proposal pipeline. Not a product for sale; a single delivered engagement.
The pipeline assembles and generates drafts. A person reviews, edits, and submits nothing it produces without reading it first.
The friction
A business that assembles proposals or quotes routinely runs the same assembly line before any substantive writing starts. Find the last proposal that was close enough to reuse. Copy it and hunt down every stale reference the last engagement left behind. Rewrite the sections that describe the company and the method. Reformat the document to match the requested structure. Then generate the summary, the slide deck, and the internal summary of what was promised.
None of that work differentiates the bid. All of it competes with the time that does: the specifics of the client's problem, the evidence that the approach has worked before, and the judgment about what to leave out. The reassembly is also where errors hide, because a reused section quietly describes a past engagement instead of the current one.
What I built
I built a proposal pipeline for a client whose team was losing days to reassembly on every proposal. Three pieces of it do the work.
Tokenized narrative templates
The recurring document is a ten-section technical narrative, where each section answers a question a reviewer will ask. Templates for it are tokenized: repeated structure and boilerplate live in the token, engagement-specific content fills it in per proposal. The fixed parts stay consistent; the parts that differ stay isolated where the differences are.
A searchable corpus of prior work
Past solicitations, proposals, and technical material are indexed into a searchable corpus, built on an open-source vector database. Before drafting, the pipeline surfaces what the client has already written that is relevant to the new opportunity, with the source text to check it against. Claims about prior work are grounded in the indexed source, not remembered.
Automated digest and deck generation
Once the narrative exists, the pipeline generates the companion documents from it: a condensed digest and an HTML slide deck. The content is derived, not retyped, so the deck and the digest say what the narrative says.
What exists today
The pipeline runs on a client's proposal work: 18 modules, 5,647 lines of code, 25 unit tests. This page records what was delivered; client identity is withheld.
How it's built
The same design rule holds across the whole thing: deterministic structure, reviewed content. The repeated document structure, the section numbering, the generated deck markup, and the assembly steps are code. A model-assisted step may draft text inside a labeled slot, but the unit tests and the templates constrain where that can happen. The git repository is the system boundary: the automation reads and writes inside it, every generated artifact is tracked, and a proposal's history is the same version history as the code. The corpus search is a local index, so prior work does not leave the repository to be searched.
What it does not do
It is single-operator tooling. There is no multi-author review workflow, no approval chain, and no editing interface a team would use day to day; those are the parts of a production build for a client that I have not needed for one person. It is not a product, and it does not generate claims. It assembles the document and drafts the fixed parts; the substance of a response still comes from knowing the work, which is not automatable and should not be.
What a client engagement would deliver
The pattern transfers: map the document your business reassembles routinely, tokenize what stays fixed, index the past work that backs new claims, and generate the companion documents from the source narrative instead of retyping them. A Pilot applies that pattern to one of your document types, against your own templates and past work, with your review steps kept in place. A Production build, scoped after the pilot, turns it into tooling your team operates under its normal approval workflow.
How to engage
Three ways to engage, in order:
- Scoping call (free, 30 minutes). Diagnose where the reassembly hours go in your proposal, quote, or report workflow and decide together whether a pilot is worth it.
- Pilot. One document type, your templates and past work, scoped before it starts. Validates the pattern against your material.
- Production build. Scoped after the pilot. The pilot becomes tooling your team can operate under its normal approval workflow.
All engagement is on standard McIntosh Consulting LLC terms.