An AI tender analysis platform, in production and still growing.

Context

Bidding is a filtering problem before it is a writing problem.

Public tenders and enterprise RFPs arrive as document sets, not documents: the notice, the specification, annexes, response templates, pricing schedules, and clarifications that get published mid-cycle. The requirements that decide the bid are spread across all of them.

Before a bid team can write anything, somebody has to read that whole set and answer one question: is this worth our time? Answering it well is expensive, and answering it slowly is worse — the qualifying work happens on the same clock as the deadline.

Our client came to us with that problem at scale, and with a view of the market: this is not one company's inconvenience, it is how the whole bidding process works. That is why the answer was a product rather than an internal script.

Challenge

Days of expert reading, spent mostly on bids that never happen.

Every incoming tender had to be qualified by hand. Someone senior worked through dozens of attachments looking for mandatory criteria, scored criteria, disqualifiers, and the small print that quietly rules a company out. That reading took days per tender.

The cost of that work is not just the hours. It is the tenders that get skipped because there was no capacity to look at them, and the ones that get pursued too long before somebody notices a requirement the company cannot meet. In tender work a missed requirement is not a rough edge — it is a non-compliant bid, no matter how strong the offer behind it was.

The client needed the reading compressed to the point where qualifying a tender stops being a decision in itself, so the team can spend its expertise on the bids worth writing.

Solution

A product that reads the full document set and reports back.

We built an AI tender and RFP analysis platform: a user uploads the complete tender pack, the system works through it, and the output is a structured audit of what the tender actually demands — requirements sorted by weight, reconciled across documents, and a clear read on whether the tender fits.

The design constraint that shaped everything was verifiability. A bid team cannot act on an answer it has to take on faith, so the output is built to be checked: a reviewer confirms what the analysis found instead of re-reading the pack, and a person still makes the bid decision. The system removes the reading, not the judgement.

It was built as a real product from the start — accounts, subscriptions, and the operational parts a SaaS needs to run without us standing next to it — and we have kept building it since launch rather than handing over a delivery and leaving.

Client confidential at their request, and that includes the mechanics: how the analysis works internally is theirs, not ours to publish. Everything on this page is what we can say with their interests intact. Supporting stack: Claude, FastAPI, Next.js, pgvector on GCP, with Stripe for billing.

Result

From days of manual review to minutes.

That is the shift the product delivers: qualifying a tender is no longer a multi-day reading job. On the platform as it runs today, a full audit completes in about 15 minutes — typically 5 to 20, depending on how large the document set is.

Those are two separate honest statements, and we keep them separate on purpose. "Days" is what manual review costs, and it varies with the pack. "About 15 minutes" is what the analysis takes now. We are not going to dress that up as one measured stopwatch comparison, because it never was one.

The durable result is the one that is hardest to fake: the product is in production with active users, and the client keeps paying us a monthly retainer to extend it. Software that survives contact with real users, and a client who renews, are the two proofs we trust most.

Related