MR.
CASE STUDY · 03 / 04
B2B SAAS · BETA

VendorQ.

The two-week security questionnaire, compressed to a two-hour review.
ROLE
Founder · Sole engineer
PERIOD
2025 — beta Q3 2026
STATUS
Closed beta · 3 design partners
READ
≈ 6 min
CHAPTER 01
THE BRIEF

The vendor questionnaire is a tax on every B2B sale.

Three hundred questions. Two weeks of back-and-forth between sales, security, legal, and engineering. The same answers, rewritten, for every prospect. Repeat per deal.

Every company selling into the enterprise pays this tax. The information already exists — in the SOC 2 report, in the pen test PDF, in the architecture overview, in last quarter's policy doc — but nobody has the time to find the right paragraph and translate it into the prospect's preferred phrasing for the eleventh time this month.

The first design partner I spoke to had a single shared spreadsheet with thirty thousand pre-written answers, organised by tab. A senior engineer would spend a full day per questionnaire copy-pasting and adapting them. Their CISO described it as "the most expensive search engine in the company".

VendorQ exists because that workflow is one of the few B2B problems where retrieval-grounded LLMs are not a gimmick — they are the obvious tool, and the obvious tool nobody has shipped well yet.

CHAPTER 02
THE APPROACH

Answers grounded in the source. Citations the reviewer can audit.

The quiet failure mode of every "AI for questionnaires" tool I tried before building this was the same: the model would generate a plausible answer with no provenance, and a senior engineer would still have to verify each one against the actual artifact. That is not a workflow improvement. That is a different kind of busywork.

VendorQ inverts the order. Every answer is generated against retrieved chunks from the customer's own document corpus — SOC 2, ISO, policies, prior questionnaires — and every sentence ships with a citation back to the exact paragraph it was derived from. The reviewer reads the answer, glances at the source, and approves or edits. The model never speaks without showing its work.

The retrieval layer is unfashionably plain: hybrid BM25 + dense, a re-ranker, and a small in-house pass that prefers chunks the customer has previously approved as authoritative. The model is whichever frontier model the customer prefers, behind a thin abstraction. The interesting product work is everywhere else.

FIG. 01 · ANSWER PIPELINE
QUESTION FROM QUESTIONNAIRE RETRIEVE BM25 + DENSE PREF: APPROVED RE-RANK GENERATE SENTENCE → CITATION CUSTOMER-CHOSEN MODEL REVIEW + CITATIONS SOURCE: SOC 2 · POLICIES · PRIOR Q&A
"An LLM that cites its sources is a research assistant. An LLM that does not is a liability with a confident voice."
CHAPTER 03
FROM THE BETA

What three design partners taught me.

The wrong assumptions died fast. The product that came out of the first quarter of beta looks almost nothing like the original wireframes — and the parts that survived were the ones I would have cut if the design partners had not pushed back.

L.01 · CITATIONS ARE THE PRODUCT

Reviewers trust the answer in proportion to the citation.

Without a click-through to the source paragraph, the answer was treated as draft. With one, it was treated as a candidate to approve. The citation is what moves the workflow.

L.02 · CLONE THE ANSWER SET

The "house style" is half the work.

Every customer phrases their answers a particular way. A clone-this-question feature that lifts the tone and structure from approved prior answers turned out to be more loved than the model itself.

L.03 · SECURITY DOES THE REVIEW

Sales submits, security approves.

The user we designed for was sales. The user that actually drove adoption was the security engineer who had been doing the work all along — and who finally had a queue instead of a fire hose.

L.04 · MIXED CORPUS WINS

Policy + prior answers + audit reports beats any single source.

The corpus that produced the highest first-pass approval rate was the one that mixed all three. Prior questionnaires gave tone; policies gave authority; audit reports gave the specific evidence reviewers wanted to see cited.

CHAPTER 04
THE PRODUCT

The thirty-second loop.

Upload the corpus. Drop in the questionnaire — XLSX, CSV, vendor portal export. The first pass runs in under a minute on a typical three-hundred-question doc. Each row arrives with a draft answer, a confidence band, and a stack of citations.

The reviewer works the queue: approve, edit, escalate. Approved answers feed back into the corpus and start showing up as preferred sources for the next questionnaire. Over time the system learns the company's voice, not just its facts.

vendorq · API call · simplified
# programmatic access for teams that wire it into their CRM
POST /v1/questionnaires/answer
{
  "corpus_id": "acme-2026-q1",
  "questions": [
    "Do you encrypt customer data at rest?",
    "Describe your incident response plan."
  ]
}

 200 OK
{
  "answers": [
    {
      "text": "Yes. AES-256 at rest, managed by AWS KMS...",
      "confidence": 0.94,
      "citations": [
        { "doc": "soc2-2025.pdf", "page": 14 },
        { "doc": "data-policy.md", "section": "3.2" }
      ]
    },
    ...
  ]
}
CHAPTER 05
THE OUTCOME

Two-week process, two-hour review.

Across the three design partners, the median time from "questionnaire received" to "questionnaire returned" went from roughly two weeks to roughly two hours of focused security review — a ~70% reduction depending on questionnaire size and the maturity of the corpus.

The number we actually care about is downstream: how many deals close. Too early to claim a clean attribution, but every partner has reported the same anecdote: the security questionnaire stopped being the long pole. That is what the product was built to do.

VendorQ enters open beta in Q3 2026. The roadmap from here is unsexy and focused: tighter portal integrations, better long-context citation rendering, and a slow expansion of the corpus types the indexer handles natively.

— END OF REPORT —