South Africa's eTenders portal publishes thousands of government procurement opportunities. In theory, that's transparency. In practice, it's a wall of unstructured listings that's hard to search, impossible to analyse at scale, and gives suppliers no insight into who actually wins, what a competitive price looks like, or which opportunities are worth the effort of bidding. Municipal procurement data sits in a separate set of portals again, with no unified view across national and local government.
We built TenderCity to close that gap — not as a theoretical exercise, but because we kept meeting suppliers, from SMMEs to established firms, who were bidding blind. They could see the tender. They couldn't see the market around it.
The problem with tender discovery in South Africa
The raw data problem is real, but it's not the whole story. Suppliers don't just need a list of open tenders — they need to know whether a specific opportunity is winnable. That means historical award values to price competitively, visibility into which vendors dominate which categories, and some sense of how much competition and friction a given tender actually involves. None of that exists in the public data as published. It has to be built.
The tender documents themselves are another layer of the problem. Requirements, evaluation criteria and scope are buried in PDF attachments that vary wildly in structure from one organ of state to the next. A supplier evaluating ten opportunities in a week can't manually read and extract the key decision signals from ten different PDF formats and still have time left to write competitive responses.
What we learned about supplier pain points
Talking to suppliers before and during the build surfaced a consistent pattern: the hardest part of tendering isn't writing the proposal, it's deciding whether to bid at all, and then pricing it once you've decided. Suppliers were relying on gut feel and word of mouth to answer questions that were, in principle, answerable from public data — if that data had been aggregated, cleaned and connected to award outcomes.
We also learned that vendor and buyer intelligence matters as much as the tender listing itself. Knowing which vendors have historically won in a category, and which organs of state have consistent procurement patterns, changes how a supplier allocates their limited bidding effort. That's why TenderCity builds vendor profiles (award history, spend totals, category focus) and buyer profiles (procurement frequency, spend patterns) alongside the raw tender feed, rather than treating tenders as isolated, disconnected listings.
Technical lessons from building the platform
TenderCity's pipeline ingests tender records continuously from the national eTenders portal and provincial municipal sources, using Python pipelines to fetch, clean and sync the data. The platform runs on Google Cloud, with Firebase handling authentication and hosting, and AI enrichment (drawing on both OpenAI and Gemini) used to extract structured intelligence — scope summaries, requirements, evaluation criteria — from unstructured tender documents.
A few lessons stood out:
Data quality has to be enforced at every stage of the pipeline, not patched at the end. Government procurement data is inconsistent — different departments format the same fields differently, and awarded-tender records don't always link cleanly back to the original tender listing. Trying to fix that with cleanup scripts after ingestion is a losing game. It has to be handled as records flow through the pipeline, with rules enforced continuously.
AI enrichment needs a human review layer, not blind trust. Extracting structured fields from a tender PDF using AI works well most of the time, but "most of the time" isn't good enough when a supplier is making a bid-or-pass decision on the output. TenderCity runs a review queue for enriched records specifically so summarisation errors get caught before they influence a supplier's decision, rather than treating AI output as ground truth.
Vendor alias detection matters more than it sounds like it should. The same company appears in award records under slightly different names — a trading name here, a registered name there, a typo somewhere else. Without alias detection and a master vendor registry, award history analysis silently fragments across what looks like dozens of different suppliers instead of one.
Product lessons from early validation
The earliest version of TenderCity focused purely on tender discovery — a searchable feed of open opportunities. That was useful, but it didn't change supplier behaviour, because discovery was never the hardest part of the problem. What moved the needle was adding bid decision support: pricing context from historical award values, participation friction scoring, and a simple compete-or-pass card per tender. Suppliers didn't just want more data. They wanted the data translated into a decision.
That's a pattern worth naming explicitly, because it generalises well beyond tenders: raw data aggregation is rarely the product. The product is the judgement layer built on top of the data — the part that tells a busy decision-maker what to actually do next.
Where TenderCity can go next
The platform's roadmap follows directly from what suppliers ask for once they're using it: deeper participation-friction scoring, expanded municipal coverage, and tighter integration between tender discovery and the kind of reusable capability pack we cover in a companion article on tender response automation — so that identifying a winnable opportunity and assembling a strong response become one connected workflow rather than two separate efforts.
How CloudNala applies these lessons to client work
Building TenderCity taught us things that show up in every data and AI engagement we run for clients since — that pipelines need data quality enforced at every stage, that AI enrichment needs human review built in rather than bolted on, and that the real value in any data platform is the decision-support layer, not the raw aggregation. We bring that same discipline to client projects, whether we're building a bespoke platform or advising on an existing one.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Explore TenderCity or speak to CloudNala about building your own digital product — consult@cloudnala.co.za