Tender Discovery Platform Case Study

A subscription platform for finding and winning public-sector tenders. A business says what it bids on, the product watches the authorities' feeds, and anything relevant arrives sorted by how long there is left to respond.

I took it from the idea. Research, the stakeholder sessions that settled what we were actually building, the information architecture, wireframes, and the high-fidelity screens across onboarding, discovery, tender detail, pipeline, alerts, billing and settings, on one design system.

Public tenders are legally published. They are not practically findable. Notices sit across dozens of separate authority portals in inconsistent formats, attached to document bundles running to several hundred pages, against deadlines that do not move.

Small and mid-sized firms lose work they could have won without ever seeing it. The ones who do see it lose most of a day deciding whether it is worth bidding on. Neither of those is a bidding problem, which is why neither is solved by bidding harder.

I read the source material before I drew anything: real notices, real document bundles, real evaluation criteria across several categories. The structure is consistent enough to parse and inconsistent enough that nobody wants to do it by hand twice.

Then I looked at what businesses already use. The authority portals, email digests, a spreadsheet, and in more than one case a person whose morning job is checking sites. The tools were not the process. The spreadsheet was the process, and that is what the product actually had to replace.

Back-to-back sessions with the founders to settle the ambiguities before design started: which business we serve first, what the free tier is allowed to show, what ships in v1, and where the money sits.

The decision everything else hangs from: we charge for the documents, never for the notice. A tender's existence, its authority, its value and its closing date are public information, and selling those back to people would be selling something that is not ours. What the product sells is the finding, the structuring and the warning. That one line settled the paywall, the pricing and about half the copy.

I sat with people who bid for a living. The same shape came up every time: discovery is annoying, but qualification is the expensive part. Everyone had a story about spending a day inside a document bundle and finding out at the end that they were never eligible.

Two findings changed the design. Nobody reads a tender to learn about it, they read it to decide whether to bid, and those are two different documents inside the same file. And a perfect match closing in four days is worth less than an average one closing in three weeks, because a bid takes time to write. Relevance without time left is not an opportunity.

The spine is a week, not a session. Alerts arrive, the dashboard shows what is closing, a few tenders get qualified in a couple of minutes each, one or two enter the pipeline, and the rest are dismissed deliberately so they stop coming back.

Onboarding exists to solve the cold start. The questions asked at sign-up (what brings you here, what you are looking for, what matters to you) are not segmentation for marketing. They seed the first set of matches so the first dashboard has real tenders on it. A discovery product that opens empty has already lost the user.

One accent green for action, and a status set where every value carries exactly one meaning: open, closing soon, closed, submitted, won, lost. A status reads identically in a table row, a pipeline card and a notification, so nobody has to learn it twice.

Deadline is the primary sort everywhere, ahead of relevance. That was argued about, because relevance is what the matching is proud of. Time remaining is what decides whether a person can act at all, so it takes the top of every list and every card.

The tender detail took the most rounds. The first version led with the document bundle, which is faithful to the source and useless to a reader, it asks someone to open several hundred pages to find out whether they are eligible.

It was rebuilt to qualify before it describes. Value, closing date, category, eligibility and evaluation criteria sit at the top; the documents sit below. The first question the page answers is should I bid, not what is this. Every version after that one got shorter.

Discovery is a list and a map, because geography is a hard filter in procurement rather than a nice visualisation, a firm bids where it can actually deliver. Filters narrow, the map bounds, and the list stays sorted by time left.

A locked tender shows everything public and blurs only the bundle, and the unlock states plainly what is behind it rather than teasing. Alert setup is a short wizard rather than a settings page, because the people who need alerts most are the least likely to go hunting through preferences. Pipeline, notifications, plan and billing cover what a subscriber manages after that.

Seven core surfaces taken from the idea: onboarding, the dashboard, discovery with its paired list and map, the tender detail, the pipeline, alerts and notifications, and plan and billing, with the pricing page built on the same rule as the paywall.

One line held from the first stakeholder session to the last screen: charge for the documents, never for the notice. It gave the free tier a real job and made the paywall explainable in a sentence. This was a design engagement rather than a measured launch, so there is no figure here. The one to watch is what share of alerted tenders get qualified rather than ignored, because that is the difference between a subscription people keep and one they cancel.

Charging for the documents and not the notice was the highest-leverage decision in the project. It gave the free tier a real job, made the paywall explainable in one sentence, and kept us from selling public information back to the public.

What I would do differently: I designed the alert wizard after discovery rather than alongside it. Discovery is what someone does in week one; alerts are what they pay for in month six. The feature carrying retention should not have been the last one designed.