Licitador

Peruvian public tenders are published as 50–300 page PDFs, often scanned. A company that sells to the state burns 3–6 hours per tender just working out whether it qualifies — and most of the time the answer is no. Licitador does that reading every night: it pulls the new tenders from the state procurement platform (SEACE/OECE), downloads the bidding documents, OCRs only the pages that need it, and scores each tender against the client's own company profile.

The hard part isn't summarising — it's being trustworthy enough to act on. Every extracted requirement, deadline and guarantee comes back from Claude as structured output carrying a page number and a verbatim quote, and the code re-checks that quote against the real text of that page before it is ever shown. Anything that fails verification is discarded rather than displayed. That constraint is what makes the output auditable by a client's legal team instead of just plausible.

It runs as two services against one Postgres: a Next.js app (Better Auth organizations for multi-tenancy, Drizzle, pgvector) and a Python worker that does ingestion, OCR, chunking, embeddings and analysis. The job queue is a plain Postgres table using FOR UPDATE SKIP LOCKED — no Redis, no Celery — so retries, backoff and orphan reaping are all just SQL.