Building BidScribe: From Idea to Production

Responding to RFPs is painful. Every B2B company knows it — you get a 50-page document full of questions, and your team scrambles to piece together answers from previous proposals, internal docs, and tribal knowledge. Under deadline pressure.

I built BidScribe to fix that.

The Idea

The core insight is simple: most RFP answers aren't novel. They're variations of things your company has already written. The challenge is finding the right previous answer and adapting it to the current context.

This is a perfect use case for RAG (Retrieval-Augmented Generation). Build a knowledge base from your best answers, retrieve the most relevant ones for each new question, and let an LLM synthesize a tailored response.

Tech Decisions

I went with Next.js + Supabase — a stack I know well and that lets me move fast as a solo developer.

Why Supabase over Firebase? Three reasons:

1. pgvector — vector similarity search natively in PostgreSQL
2. Row Level Security — multi-tenant isolation without application logic
3. Edge Functions — serverless compute without leaving the ecosystem

What I Learned

Building a RAG system that works in demos is easy. Building one that works in production is a different game. Chunking strategy, embedding quality, and retrieval relevance matter more than which LLM you use.

More on the technical details in a future post.