The UK public sector represents one of the country’s largest commercial markets, yet it is often presented to suppliers through classifications, notice structures and terminology designed around procurement systems rather than the businesses expected to use them. CPV Finder was created to close that translation gap. A supplier describes what it does in ordinary language, reviews a recommended set of Common Procurement Vocabulary codes and then uses that profile to explore relevant notices published through the UK Find a Tender service.
The address is deliberately simple: cw.is/cpv. The problem behind it is not.
A large market hidden behind a translation problem
The UK’s new public procurement regime came into force on 24 February 2025. The government presented the reforms as a way to improve transparency, strengthen competition and give smaller businesses better access to nearly £400 billion of annual public procurement expenditure.
That is an enormous addressable market, but “addressable” is not the same as accessible.
A capable supplier can still fail to discover a suitable opportunity because it searches using the language found on its website, while the buyer has classified the notice using a vocabulary the supplier has never encountered. The company may have the staff, experience and technical capability to deliver a contract, yet still fail to find it because the two parties describe the same requirement differently.
That vocabulary is CPV, the Common Procurement Vocabulary. It provides a standard way to describe the supplies, services and works being purchased through public procurement.
The official vocabulary is hierarchical. Its opening digits identify progressively narrower divisions, groups, classes and categories, while the complete code points towards a more specific procurement subject. CPV 2008 remains the current version of the vocabulary.
This hierarchy is valuable for publishing, comparing and analysing procurement notices, but it creates an immediate usability problem.
Businesses do not naturally introduce themselves as:
72222100
or:
90910000
They say that they provide information-systems consultancy, commercial cleaning, catering equipment, construction, professional training or cyber-security testing.
This is more than a cosmetic inconvenience. Search language directly influences commercial visibility.
A supplier that chooses a code that is too broad may be overwhelmed by irrelevant notices. A supplier that chooses only one highly specific code may miss work published under a parent category or neighbouring classification. A first-time public-sector bidder may not know whether it needs a product code, service code, installation code, maintenance code, consultancy code or a combination of several related classifications.
The resulting friction appears at the very first stage of market participation. It occurs before the business has assessed the requirement, checked its eligibility, formed a consortium, calculated a price or written a bid.
CPV Finder was created because this first stage can be improved without expecting every supplier to become a procurement-classification specialist.
Its purpose is not to replace official guidance, buyer documentation or professional judgement. Its purpose is to provide a better starting point by translating a natural-language description of a business into an understandable and editable procurement profile.
The live application does not begin with a wall of codes or a complex technical filter. It begins with a plain question:
What does your business provide?
Users are encouraged to describe their main services, products, sectors and specialist capabilities. The system proposes an initial shortlist, the user refines it and the resulting selection can be exported or used to search recent Find a Tender notices.
This three-stage journey—describe, refine and use—is the central product decision behind the current MVP.
How the product works—and why the design matters
The current application is intentionally lightweight.
It runs on PHP and browser-based JavaScript, uses a locally installed copy of the official CPV vocabulary and retrieves public notice data from Find a Tender. Find a Tender makes notice information available as Open Contracting Data Standard JSON through its release-package API.
This architecture matters commercially as well as technically.
It keeps early infrastructure costs low, allows the application to operate on ordinary shared hosting and makes the product easier to maintain while its most valuable use cases are being validated. The project does not need to carry enterprise-scale cloud costs before it has enterprise-scale demand.
The first release should not be presented as a mysterious artificial-intelligence system. Its current recommendation method is deterministic, inspectable and explainable.
The application normalises the supplier’s description, removes common words, expands selected business phrases into related expressions, applies basic word stemming and assigns weighted scores to the labels in the CPV vocabulary.
A description containing “cyber security”, for example, can be expanded with terms such as information security, penetration testing, incident response and network security. The vocabulary is then ranked according to the strength of the wording match and the position of each result in the CPV hierarchy.
A simplified version of the browser request looks like this:
const params = new URLSearchParams({
q: businessDescription,
limit: '18',
mode: 'suggest'
});
const response = await fetch(`api/cpv.php?${params}`);
const { items } = await response.json();
The important product behaviour begins after the response is received.
The strongest suggestions are initially selected to reduce effort, but the application does not silently treat them as unquestionably correct. The user remains responsible for reviewing the shortlist.
They can remove an unsuitable recommendation, explore broader or more specific alternatives, search for another term or add a particular CPV code manually.
This human-in-the-loop design is essential.
Procurement classifications can be ambiguous. Buyers do not always classify similar requirements in identical ways. One business may operate in several connected markets, and a short description may not communicate every part of its offer.
The purpose of automation is therefore to reduce the size of the search problem rather than to conceal uncertainty.
Inside the recommendation service, the present scoring is deliberately straightforward. The following shortened excerpt illustrates the principle:
if ($query !== '' && str_contains($label, $query)) {
$score += 24;
}
foreach ($words as $word) {
$stem = stem_word($word);
if (str_contains($label, $word)) {
$score += 8;
} elseif (
mb_strlen($stem) >= 4 &&
str_contains($label, $stem)
) {
$score += 4;
}
}
This is not intended to be the final intelligence layer. It is a transparent baseline against which future improvements can be measured.
It also establishes the beginnings of a valuable feedback loop.
Which recommendations do users retain? Which do they remove? Which additional codes do they search for? Which business descriptions produce no useful results? Which suggested code ultimately leads the user to open an official procurement notice?
Those interactions can become evaluation data for a more sophisticated ranking model, provided the information is collected with appropriate consent, privacy safeguards and governance.
A future system might use machine learning or language embeddings to understand more nuanced supplier descriptions. The important point is that new methods should be evaluated against the transparent baseline rather than introduced simply so the product can be described as “AI-powered”.
The second half of CPV Finder addresses another common weakness in procurement search: exact matching.
An early interpretation of the 60% threshold required a contract notice to contain most of the codes selected by the supplier. That sounds reasonable until it encounters real procurement data.
A supplier might create a thoughtful profile containing ten connected CPV codes. A buyer, however, may publish the corresponding opportunity with one principal code and only one or two supplementary classifications. Requiring six exact matches would reject an otherwise highly relevant opportunity.
The current matching logic therefore treats the CPV vocabulary as a hierarchy.
An exact code match receives the highest score. A notice code within the same detailed category receives a strong score. Matches at class and group level receive progressively lower scores.
This makes the percentage a measure of hierarchical CPV relevance rather than a simple count of how many selected codes were repeated in the notice.
function cpv_similarity(
string $selected,
string $notice
): float {
if ($selected === $notice) {
return 1.00;
}
if (
substr($selected, 0, 5) ===
substr($notice, 0, 5)
) {
return 0.85;
}
if (
substr($selected, 0, 4) ===
substr($notice, 0, 4)
) {
return 0.72;
}
if (
substr($selected, 0, 3) ===
substr($notice, 0, 3)
) {
return 0.60;
}
if (
substr($selected, 0, 2) ===
substr($notice, 0, 2)
) {
return 0.42;
}
return 0.00;
}
These weights are product choices, not official procurement rules.
Their value is that they can be tested and calibrated. A 60% threshold currently allows opportunities classified within the same CPV group to be included, while a user seeking greater precision can raise the threshold.
Over time, the relevance calculation could incorporate the notice title, description, buyer type, geographic area, estimated value, procedure, submission deadline and feedback from previous searches.
The CPV relationship should nevertheless remain an explainable part of the answer. A supplier should be able to understand why a notice was shown rather than being asked to trust an unexplained relevance percentage.
Find a Tender provides an appropriate official discovery layer because its open-data service exposes notices in a machine-readable format.
CPV Finder can retrieve recent releases, extract their classifications, compare them with the supplier’s selected profile and provide links back to the original notice.
The application does not attempt to become the legal or definitive source of the procurement. It helps the supplier reach the official source with a better-informed search context.
The export function serves a different but equally practical purpose.
A CPV shortlist can be useful beyond one search session. It can be shared with a bid writer, included in an opportunity plan, reviewed with a business adviser or used to configure procurement alerts elsewhere.
The present browser-based PDF export is intentionally inexpensive and dependable. A future subscription product could extend it with branded supplier profiles, saved versions, collaboration, approval controls and an auditable history of changes.
What the live MVP proves—and what it still needs to prove
The most important fact about CPV Finder is that it is live.
A visitor can move from an ordinary description of a business to a shortlist of procurement classifications without downloading software, configuring a database or learning the CPV hierarchy before starting.
That demonstrates technical feasibility. More importantly, it communicates the proposition in a form that suppliers, partners and potential investors can experience directly.
The MVP also demonstrates that a useful procurement-discovery workflow can be delivered with modest infrastructure.
The application uses common web technologies. The CPV vocabulary is stored locally. Public notice responses are cached to reduce repeated requests and lower the load placed on both the host and the official data service.
This produces favourable early economics. Infrastructure expenditure can remain proportionate while the product team learns which parts of the experience generate repeat use and genuine customer value.
A live MVP, however, is evidence of execution rather than evidence of product-market fit.
Several expectations should be stated clearly.
CPV Finder makes recommendations; it does not issue definitive classifications. The quality of its contract matching is partly dependent on the accuracy and completeness of the classifications published by buyers.
Public APIs can change. Service availability can affect performance. A manually maintained synonym map will not immediately understand every specialist industry, technical phrase or regional expression.
Users must still verify the official notice, its eligibility requirements, timescales, procedure, value and supporting documents before acting.
There is also a significant commercial difference between a useful free lookup tool and a product that customers will pay to use repeatedly.
The CPV vocabulary is public. Find a Tender information is public. A competitor can recreate a basic search interface.
The durable value cannot rest solely on republishing public information. It must come from reducing recurring work and improving decisions throughout the supplier’s procurement journey.
That is why the next stage should be evaluated through user behaviour rather than vanity traffic.
The central question is not simply how many people visit the page. It is whether a visitor enters a meaningful business description, reviews the resulting shortlist, reaches an appropriate official notice and later returns to repeat or continue the process.
Recommendation quality can be measured by examining how many proposed codes users retain, how many they remove, which alternatives they add and whether they proceed to relevant notices.
The product should also measure whether users return with another business area, save a company profile, activate an alert, share a shortlist or invite a colleague.
These signals indicate whether CPV Finder is successfully translating commercial intent or merely returning labels that appear plausible.
The current live interface also needs its explanatory copy to remain aligned with the underlying matching implementation.
Where the code uses hierarchical relevance, the interface should not describe the percentage as a requirement for a proportion of exact selected codes.
This is a small wording issue, but it illustrates a larger product principle. Trust in procurement software depends on precise explanations. Users should be able to understand what a score means and why a particular opportunity has been presented.
Why this can become a business rather than remain a utility
The investor case begins with the size and persistence of the underlying market.
Public authorities will continue to purchase technology, construction, healthcare products, facilities services, professional advice, education, training, transport and thousands of other categories.
Suppliers will continue to need reliable methods for determining which opportunities are relevant to their capabilities.
The Procurement Act’s focus on transparency, competition and SME access increases the strategic relevance of supplier-enablement tools, although legislation alone cannot guarantee that smaller businesses will find or win more contracts.
CPV Finder can enter the market through a narrow and understandable problem, and then expand into a broader commercial workflow.
The initial proposition is classification:
Tell us what your business supplies, and we will help you identify the procurement language that represents it.
Once a supplier has created a trusted CPV profile, the next questions become continuous.
Which new notices match the profile? Which public bodies purchase these categories? Which existing contracts are approaching expiry? Which frameworks are relevant? Which opportunities have realistic values and deadlines? Which notices should be pursued, monitored or rejected?
The classification stage can therefore act as the entry point to a wider supplier-intelligence platform.
A freemium business model could keep the core recommendation process and occasional contract search open to all users. Paid plans could introduce saved company profiles, scheduled alerts, multiple business units, advanced filters, opportunity pipelines, team workspaces and exportable reports.
Procurement consultants and bid-writing firms could use a professional version to manage several supplier clients.
Chambers of commerce, trade associations, local enterprise programmes and business-support organisations could license a co-branded version for their members.
Procurement, accounting and commercial-intelligence platforms could eventually consume a CPV Finder API or embed the classification workflow as a white-label component.
The public vocabulary and notice feed provide a low-cost data foundation. The commercial intelligence would be created in the layer built above them.
That layer includes the mapping between genuine supplier language and procurement classifications, the ranking of opportunity relevance, the recommendations users accept or reject, sector-specific terminology and the workflow information produced as opportunities are assessed.
These advantages do not constitute a meaningful moat on the day the product launches. They represent a potential moat that must be built through usage, evaluation and effective distribution.
The relationship is circular.
More relevant users provide more representative business descriptions and refinement decisions. Those decisions can improve the language map and ranking methods. Better recommendations can produce more useful opportunity discovery.
Better discovery can support retention and a willingness to pay for monitoring, collaboration and saved intelligence. Stronger retention can make the platform more attractive to channel partners, bringing additional users into the system.
The flywheel will only work when users receive an obvious benefit and when their information is handled responsibly.
The commercial risks are equally clear.
General tender-alert platforms already exist. Some have larger datasets, established sales teams and more mature filtering capabilities. A standalone CPV lookup may generate limited willingness to pay. Public-data quality can be inconsistent, and procurement sales cycles are often slow.
The answer is not to imitate every incumbent feature immediately.
CPV Finder should seek to own a distinctive moment in the supplier journey: converting an unfamiliar business into a procurement-ready opportunity profile.
It can expand from that point using evidence, rather than becoming another unfocused tender portal.
A credible roadmap would progress in measured stages.
The first stage is to improve recommendation precision and instrument the live journey so that product decisions are supported by behavioural evidence.
The second is to introduce saved supplier profiles and dependable alerts, because these create recurring value.
The third is to enrich opportunities with buyer, value, geography, deadline and procurement-stage context.
The fourth is to introduce professional and partner workflows for organisations that manage several suppliers.
Machine learning should be added where it can demonstrably improve ranking or reduce manual refinement. It should not be used merely as a label over rules that are already understandable and effective.
The outcome CPV Finder is aiming for
For a supplier, the intended outcome is straightforward: less time decoding procurement terminology and more time evaluating genuine commercial opportunities.
A cleaning company should be able to describe the environments it serves and the work it undertakes, receive a sensible combination of cleaning and facilities-management codes, refine the selection and then see notices that are close enough to justify further investigation.
A digital consultancy should be able to distinguish its software-development, cloud, data, security, training and advisory capabilities instead of relying on one generic IT classification.
A manufacturer should be able to build a reusable profile that covers its products, installation work and maintenance services.
The wider ambition is a more navigable public market.
Better supplier discovery can contribute to wider participation, stronger competition and improved awareness of capable organisations that might otherwise miss a notice.
CPV Finder cannot deliver these outcomes alone, and it does not remove the complexity of qualification, compliance, pricing or bid preparation.
It can remove one unnecessary barrier: the expectation that every potential supplier must understand a detailed classification system before it can begin searching.
For an investor or strategic partner, the opportunity is to help turn that focused solution into a recurring supplier-intelligence product.
The live MVP demonstrates the core concept. Its lightweight architecture keeps experimentation affordable. The public procurement market provides a large and continuing field of demand.
The next proof points are measurable: recommendation acceptance, successful opportunity discovery, repeat use, alert engagement, partner adoption and conversion into paid workflows.
CPV Finder was made because the first question in public procurement should not be:
Which eight-digit code do you know?
It should be:
What can your business do?
Everything that follows—from classification to opportunity discovery—can then be built around the answer.
Explore the live application at cw.is/cpv
