Pat Lomadze
AI Automation & Backend Engineer | Agents, APIs, Data
New to Contra
Pat is ready for their next project!
Why I started building TenderScope
The construction intelligence market is not short on data.
We already have platforms for permits, tenders, early development signals, company research, competitive intelligence, and contract awards.
And many of them are very good at the specific thing they focus on.
But I kept noticing the same problem:
The signals still live in separate systems.
A land transaction may tell you something is forming.
A rezoning application may confirm development intent.
A permit may show that the project is becoming real.
A tender may reveal procurement.
An award may show who won.
Company records may tell you who is involved.
Competitor activity may tell you who is moving into the same market.
But these are usually treated as separate records, separate workflows, and separate decisions.
The user is still left with the hardest part:
Connecting everything into one picture.
That is the problem I wanted to solve with TenderScope.
The idea was never to build another permit platform or another tender database.
The goal is to connect the full construction lifecycle:
Early signals → Development → Permits → Tenders → Awards → Construction
And then connect that lifecycle to the companies involved.
So instead of seeing 10 disconnected records, you should be able to understand:
• Is this the same real-world project?
• What stage is it actually in?
• Who is involved?
• What role does each company play?
• What changed recently?
• Which competitors are moving around it?
• Is this relevant to my company?
• And most importantly: when should we act?
That last question is where I think the industry still has a major gap.
A permit by itself is not intelligence.
A tender by itself is not intelligence.
An early signal by itself is not intelligence.
The value comes from understanding how those signals relate to each other — and what they mean for a specific business.
That is the direction behind TenderScope:
One connected construction intelligence layer instead of isolated signals.
The long-term vision is simple:
You should not have to search five different systems and manually reconstruct the market.
The system should understand your company, monitor the market continuously, connect the signals, and tell you what actually matters.
All signals. One connected view.
That is why I started building TenderScope.
#ConTech #ConstructionIntelligence #AI #TenderScope
1
8
Designed an on-demand company enrichment system for TenderScope that discovers and evaluates public company contact information only when a profile is requested.
The architecture uses cache-first processing and job deduplication, with controlled web extraction through Crawl4AI/Playwright, structured JSON-LD extraction, and Trafilatura fallback. Every candidate result preserves provenance and confidence for review instead of automatically treating discovered contacts as verified.
Security controls include SSRF protection, robots.txt compliance, restricted network access, and evidence tracking.
Architecture and read-only pilot completed. Production activation is gated behind final validation.
1
15
Built a company intelligence and role-resolution system for TenderScope that connects fragmented company records across permits, tenders, contract awards and early construction signals.
The system normalizes company identities, matches records to canonical companies and verifies organizations against the OrgBook BC registry. Rather than simply identifying a company, it determines the role the company plays in a construction project — such as General Contractor, Developer, Architect, Construction Manager, Consultant or Subcontractor.
Each resolution is supported by confidence scoring and evidence, with safeguards that protect previously verified data and deadlock-safe PostgreSQL operations for reliable processing.
The result is a structured intelligence layer that turns inconsistent company mentions across multiple data sources into verified company identities, project relationships and evidence-backed construction roles.
2
35
Built a fault-tolerant orchestration layer for long-running data pipelines in TenderScope.
The system manages the full run lifecycle — running, success, partial success and failed — while preventing duplicate triggers and recovering safely from interrupted or stale runs.
I implemented lease-based execution and reclaim after restarts, stale-run recovery, coordinator locks and PostgreSQL-backed concurrency controls, then validated the behavior with real database concurrency tests.
The result is a pipeline architecture designed to recover from failures without leaving jobs permanently stuck or unintentionally processing the same work twice.
1
20