For almost every SME, buy. Building tender monitoring in-house is not a project, it is an ongoing operation: you take on a scraper for every procurement portal you care about, each with its own format, authentication, and rate limits, and each of which will change without warning. Build only when you have a requirement no vendor serves — a proprietary scoring model, a data residency constraint, or an internal system the data must live inside — and even then, buy the data and build only the layer on top.
That conclusion is not a sales argument; it follows from what the work actually is. The build side is usually underestimated because the first version is genuinely easy, and the first version is not the thing you are committing to.
What "build" actually involves
A working tender monitoring system has six parts. A prototype needs the first one. Production needs all six, forever.
Ingestion
Some portals publish a clean API or a bulk open-data feed. Many do not: they are server-rendered sites, JavaScript applications that hide their data behind session-scoped tokens, or platforms sitting behind bot protection that blocks automated requests. Each source is its own small engineering problem, and covering a second country means solving it again from scratch.
Normalisation
Once the data is in, it is inconsistent. Different date formats, different currency fields, values that are sometimes totals and sometimes annual, buyer names spelled three ways across three notices, and CPV codes present on most records but not all. Making tenders comparable across sources is more work than fetching them.
Deduplication and identity
The same contract frequently appears on a national portal and a supranational journal, sometimes with different identifiers and slightly different values. Without deduplication your pipeline double-counts, and without stable buyer identity you cannot answer "what has this authority bought before" — which is the question that makes historical data valuable.
Documents
The notice tells you a tender exists. The requirements are in the attached pack, and access to it varies enormously: some portals allow anonymous download, some require registration, some hand out a ZIP per tender, and some put documents on a different platform entirely. Any system that stops at the notice has solved the easy half.
Translation and search
Notices are published in the buyer's language. If you sell into more than one market you need cross-language search, which means a translation layer and a search index that works across it.
Monitoring and alerting
Deadlines move, clarifications are issued, notices are amended and withdrawn. You need change detection over time, not a nightly snapshot that overwrites yesterday.
The cost nobody budgets for
The build estimate almost always covers version one. What it misses is that procurement portals are moving targets. A platform relaunch, a new bot-protection layer, a changed field name, or a country migrating to a new national system all break ingestion silently — and silence is the dangerous part. A scraper that returns zero results looks exactly like a quiet week. You discover the outage when someone asks why you have not seen anything from a particular buyer in a month.
Multiply that by the number of countries you cover. One portal is a side project. Twenty-three are a team's full-time responsibility, and it is a responsibility that never converts into competitive advantage, because your competitors are reading the same public notices either way.
What buying costs you
Buying is not free of downsides, and pretending otherwise makes for a bad decision:
- Coverage is the vendor's choice, not yours. If they do not cover a market you need, you wait or you supplement.
- The matching logic is theirs. This is why explainability matters — you should be able to see why something ranked where it did and override it.
- Your workflow bends toward the product. Check that alerts, exports, and integrations fit how your team already works before you commit.
- It is a recurring cost, and a subscription is easier to cancel than a codebase is to retire — which cuts both ways.
If you build anyway, build in this order
Sometimes the constraint is real and the answer is genuinely build. In that case the sequencing matters more than the technology choice. Start with the single portal that produces most of your opportunities and get it fully working — ingestion, documents, change detection, and an alert someone actually receives — before adding a second. A narrow pipeline that is trusted beats a broad one that is quietly stale.
Then add two things most in-house builds skip: a health check that alerts you when a source returns suspiciously few records, and a manual spot-check habit where someone compares your database against the portal once a month. Both exist to catch the silent failure mode, which is the one that costs you tenders.
A five-question decision framework
- How many portals must you cover? One national portal in one country, checked by a person who is already doing that job — a saved search is enough. Three or more countries makes building an operation.
- Do you have engineers you can commit permanently? Not "can we build it" — "will someone own it in eighteen months when the portal changes and the person who wrote it has moved on".
- Is any part of this a competitive advantage? Collecting public notices is not. A scoring model encoding your win history might be.
- What is the cost of missing a tender? If one missed opportunity is worth more than a year of subscription, reliability beats control.
- Do you have a hard constraint? Data residency, air-gapped systems, or a regulator that requires the pipeline in-house are legitimate reasons to build, and they are the ones worth taking seriously.
The hybrid that usually wins
The answer for most SMEs with engineering capacity is not build-or-buy but both-in-the-right-places: buy the ingestion and normalisation layer, then build the thin layer that is specific to you. Pull tenders into your CRM, apply your own qualification rules, connect them to your capacity planning. You get the parts that reflect how your business works without owning twenty-three scrapers.
Sanity-check the buy side before you commit either way. Look at what the data actually contains — the coverage snapshot shows the volume by country and sector — and browse live tenders to see whether the opportunities you already know about are there. If a vendor's raw coverage is wrong for your market, nothing built on top of it will fix that; if it is right, the build case gets much harder to justify.