All Insights
#SundayCoffeeAndCode
May 2026

Sunday Coffee & Code - RFP Marketplace: the dry run

OK, it's Tuesday, not Sunday (I'm away on vacation). Last week I let Claude Code (Opus 4.8) loose on an idea that's been rattling around my head for ages - a multi-persona RFP Marketplace. It built the thing in ~20 minutes over plane wi-fi. This weekend, coffee in hand, I did the dry run and kept building on it.

By Steve Harris

OK, itโ€™s Tuesday, not Sunday (Iโ€™m away on vacation). Last week I let Claude Code (Opus 4.8) loose on an idea thatโ€™s been rattling around my head for ages - a multi-persona RFP Marketplace. It built the thing in ~20 minutes over plane wi-fi. This weekend, coffee in hand, I did the dry run and kept building on it.

๐—™๐—ผ๐—ฟ ๐˜๐—ต๐—ฒ ๐—ฏ๐˜‚๐˜€๐—ถ๐—ป๐—ฒ๐˜€๐˜€ ๐—ณ๐—ผ๐—น๐—ธ๐˜€

The concept: optimise the procurement loop (think Sourcewell with AI Agent support) . Every procurement runs the same painful pipeline: ๐—œ๐˜€๐˜€๐˜‚๐—ฒ โ†’ ๐—ฅ๐—ฒ๐˜€๐—ฝ๐—ผ๐—ป๐—ฑ โ†’ ๐—”๐˜€๐˜€๐—ฒ๐˜€๐˜€.

  • A buyer issues an RFP.
  • Suppliers respond, often days, weeks and sometimes months of writing.
  • The buyer assesses every response - again, often days and weeks of reading and scoring.

Slow and effort-heavy on both sides. The marketplace puts all three personas around one central hub and adds agentic support exactly where the grind is - ๐˜ณ๐˜ฆ๐˜ด๐˜ฑ๐˜ฐ๐˜ฏ๐˜ฅ๐˜ช๐˜ฏ๐˜จ and ๐˜ข๐˜ด๐˜ด๐˜ฆ๐˜ด๐˜ด๐˜ช๐˜ฏ๐˜จ.

In the Marketplace - submitters issue RFPs, defining their own fields and weighted scoring criteria. Responders upload their company knowledge once. An agent vectorises it and drafts responses grounded in their own material which they then edit. Assessors (the buyers) get an automated assessment of each response against their criteria - scored, with a written rationale and evidence quotes pulled straight from the response.

๐—™๐—ผ๐—ฟ ๐˜๐—ต๐—ฒ ๐˜๐—ฒ๐—ฐ๐—ต๐—ป๐—ถ๐—ฐ๐—ฎ๐—น ๐—ณ๐—ผ๐—น๐—ธ๐˜€ - ๐—ง๐—ต๐—ฒ ๐—ฎ๐—ฟ๐—ฐ๐—ต๐—ถ๐˜๐—ฒ๐—ฐ๐˜๐˜‚๐—ฟ๐—ฒ (๐˜๐—ต๐—ฒ ๐—ณ๐˜‚๐—ป ๐—ฝ๐—ฎ๐—ฟ๐˜)

A few principles I handed it up front as Gherkin requirements - and it stuck to them:

  • ๐—Ÿ๐—ผ๐—ฐ๐—ฎ๐—น ๐—Ÿ๐—Ÿ๐— , by design. Inference runs on a local Ollama model with a Chroma vector store for RAG (๐˜ฏ๐˜ฐ๐˜ต๐˜ฉ๐˜ช๐˜ฏ๐˜จ ๐˜ฆ๐˜ข๐˜ณ๐˜ต๐˜ฉ ๐˜ด๐˜ฉ๐˜ข๐˜ต๐˜ต๐˜ฆ๐˜ณ๐˜ช๐˜ฏ๐˜จ).
  • ๐—” ๐—ต๐—ฎ๐—ฟ๐—ฑ ๐˜€๐—ฝ๐—น๐—ถ๐˜ between front and back-ends. Static per-persona front ends talk to a backend API. The backend never calls the agents directly.
  • ๐—๐—ผ๐—ฏ + ๐—ฎ๐—ด๐—ฒ๐—ป๐˜ ๐—ผ๐—ฟ๐—ฐ๐—ต๐—ฒ๐˜€๐˜๐—ฟ๐—ฎ๐˜๐—ถ๐—ผ๐—ป. The integration boundary between the two halves is a single Postgres job queue. The backend just writes a job into the database. A separate job runner polls and safely claims the work; an orchestrator then dispatches it to independent agent services - a vectoriser, a responder agent, an assessor agent - each its own process.

Why bother? Each tier develops, scales and fails independently, every step is auditable, and you can throw more workers at the queue without touching the web app.

Still very much a POC, and the LLM output is a first draft a human refines - but the end-to-end loop works: issue an RFP, generate a grounded response, get a cited assessment on a dashboard (๐˜ข๐˜ญ๐˜ญ ๐˜ช๐˜ฏ๐˜ต๐˜ฆ๐˜จ๐˜ณ๐˜ข๐˜ต๐˜ฆ๐˜ฅ ๐˜ต๐˜ฐ ๐˜ฐ๐˜ฑ๐˜ต๐˜ช๐˜ฎ๐˜ช๐˜ด๐˜ฆ ๐˜ต๐˜ฉ๐˜ฆ ๐˜ฑ๐˜ณ๐˜ฐ๐˜ค๐˜ฆ๐˜ด๐˜ด).

Genuinely impressed with where the tooling is. Still a crazy, awesome world. More to come.

Want to Discuss This Topic?

Steve is always happy to have a direct conversation.