Inspiration

Construction estimators often spend hours searching public tender portals, municipal development feeds, email alerts, and spreadsheets before estimating even begins.

The information is fragmented, duplicated, inconsistent, and difficult to compare. Every week, estimators repeat the same manual process:

  • Collect available opportunities
  • Remove duplicate or irrelevant records
  • Determine whether each project fits the contractor
  • Rank the opportunities
  • Document why the company should pursue, monitor, or ignore them

BuildMatch originally began as a broader idea for helping construction clients, contractors, and subcontractors find one another.

During OpenAI Build Week, we narrowed that vision to a practical problem we understood directly from construction estimating:

How can a contractor identify the right opportunities faster without turning the decision into an unreviewable AI black box?

BuildMatch BC focuses on the first critical stage of the tender-to-bid process: finding, qualifying, ranking, and reviewing the right opportunity before an estimator commits significant time to takeoff and pricing.

The project was also built under real-life constraints. Our small team balanced full-time construction work, studies, a five-month-old baby, family caregiving responsibilities, and collaboration across different schedules.

Those constraints pushed us to focus on one real industry problem and build a workflow that could be demonstrated and tested honestly.


What it does

BuildMatch BC is a Windows-based opportunity intelligence and bid/no-bid support tool for construction estimators and contractors.

The user can:

  1. Select a contractor profile:
  • Civil Contractor
  • Multi-Family Residential Builder
  • General Contractor
  1. Load a stable public snapshot or refresh information from approved public sources.

  2. Normalize, validate, and deduplicate tender and development-project records.

  3. Score opportunities using editable deterministic business rules.

  4. Review ranked opportunities with visible:

  • Matched positive and negative terms
  • Fit scores
  • Routing decisions
  • Source information
  • Data provenance and freshness
  1. Select a specific ranked opportunity for optional OpenAI analysis.

  2. Compare the AI assessment with the deterministic result.

  3. Export reviewable information to Excel while preserving estimator-owned notes, statuses, and assignments.

Deterministic first, AI second

The deterministic engine remains authoritative.

The AI provides a separate, structured second opinion and cannot silently change:

  • The official fit score
  • The routing bucket
  • The matched terms
  • Manual estimator notes
  • Assignments or review status

When the deterministic engine and the AI disagree, BuildMatch clearly displays the disagreement and returns the final decision to the estimator.

The current version is an opportunity-discovery and qualification copilot.

Tender-document quantity extraction, native Bluebeam integration, and direct HeavyBid integration are planned future stages and are not presented as completed functionality.


How we built it

BuildMatch BC is a Python desktop application with a Tkinter interface and Excel-based outputs.

Core workflow built with Codex

Codex was used to build the original core workflow, including:

  • Public-source connector sweeps
  • Engine orchestration
  • Deterministic keyword scoring
  • The configurable source registry
  • Excel workbook outputs
  • The base desktop interface

Build Week improvements

During OpenAI Build Week, the project was expanded with:

  • Civil, Multi-Family Residential, and General Contractor profiles
  • Full public-source refresh from the GUI
  • Data normalization and deduplication
  • Deterministic ranking and routing
  • Ranked-opportunity selection
  • Visible data mode, provenance, and freshness
  • Truthful current-run metrics
  • Last-known-good recovery after failed refreshes
  • A stable public snapshot for repeatable demonstrations
  • Optional OpenAI opportunity analysis
  • Automated tests and package verification
  • Security and privacy controls
  • Windows continuous integration

OpenAI integration

The AI feature uses the OpenAI Responses API with strict JSON Schema structured output.

Only approved public opportunity information and deterministic scoring evidence are sent to the model.

The following information is excluded:

  • Private estimator notes
  • Assignments
  • Contact details
  • Local file paths
  • Credentials
  • API keys

The OpenAI API key is read from an environment variable. It is never written to the repository, Excel workbooks, logs, manifests, or cache identifiers.

All deterministic scoring, ranking, review, and export functions continue to work without an API key.

Transparent use of development tools

Claude Code was also used transparently for:

  • Independent code review
  • Security and privacy analysis
  • Sanitization
  • Test-gap identification
  • Documentation
  • Targeted corrections

Human ownership remained responsible for:

  • Construction and estimating knowledge
  • Business rules
  • Acceptance criteria
  • Privacy decisions
  • Product direction
  • Final review of AI-generated work

Challenges we ran into

Inconsistent public sources

Municipal portals and tender sources use different schemas, terminology, project stages, and formats.

Some sources:

  • Change their structure
  • Return incomplete records
  • Block automated access
  • Require manual review
  • Become temporarily unavailable

Instead of describing every configured source as operational, BuildMatch separates:

  • Configuration validation
  • Offline parser testing
  • Controlled live-source verification
  • Manual-only status
  • Blocked or unavailable status

This prevents historical or unverified source information from being presented as current fact.

Building AI without removing human control

It would have been easier to ask an AI model to create one final score and automatically decide whether to bid.

We intentionally avoided that approach.

BuildMatch uses a hybrid workflow:

  • Deterministic rules produce the authoritative result
  • OpenAI produces an advisory assessment
  • Supporting evidence is displayed
  • Missing information is reported
  • Uncertainty is visible
  • Disagreements are highlighted
  • The estimator makes the final decision

Keeping metrics truthful

An earlier offline report displayed a historical live-fetch number even when no live collection had occurred.

We treated that as a release-blocking issue.

Offline runs now report:

  • Records pulled live: 0
  • The actual number of records loaded from the selected input or public snapshot
  • A clear status explaining that live acquisition was skipped

The system distinguishes between:

  • Live data
  • Cached-live data
  • Public snapshot data
  • Synthetic data
  • Mixed data
  • Unknown data

Protecting the workflow when a refresh fails

Public-source acquisition can fail because of timeouts, changed websites, incomplete records, or other external conditions.

A failed refresh must not damage the last useful dataset.

We implemented:

  • Validation before dataset promotion
  • Atomic file replacement
  • Failure manifests
  • External runtime state
  • Last-known-good recovery
  • Visible stale or cached-data warnings

Testing across operating systems

Testing uncovered Windows-specific issues that did not appear during Linux testing, including Excel workbook file-handle behaviour.

Remote Windows CI helped identify and correct those problems before submission.

Protecting Excel outputs

Public fields can begin with characters that spreadsheet applications interpret as formulas.

We added formula-injection protection so untrusted public values are written as literal text rather than executable spreadsheet formulas.


Accomplishments that we're proud of

We are proud that BuildMatch BC is a working application rather than only a concept or interface mock-up.

The current project includes:

  • A functional Windows desktop interface
  • Configurable contractor profiles
  • Editable deterministic scoring rules
  • Public-source connectors
  • Data normalization and deduplication
  • Ranked opportunity review
  • Optional structured OpenAI analysis
  • Excel-based review and audit outputs
  • Visible data provenance
  • Failed-refresh recovery
  • Security and privacy protections
  • Automated offline testing
  • Windows CI verification

Repeatable public-data demonstration

We created a stable demonstration snapshot containing 82 sanitized public records from approved municipal feeds.

This allows the main workflow to be demonstrated without depending on external websites being available during judging.

Real defects found through testing

A controlled live refresh and subsequent audits helped identify and correct real issues, including:

  • Missing deterministic scorer wiring
  • Incorrect ordering of scoring and dataset promotion
  • Misleading historical metrics
  • Incomplete-record validation
  • Concurrent file-writing risks
  • Windows workbook-handle problems
  • Excel formula-injection exposure
  • GUI performance problems
  • Finished-project filtering behaviour

We are also proud of the project’s transparency.

The repository documents:

  • What was built with Codex
  • What was reviewed or corrected with other tools
  • What was tested
  • What remains unverified
  • Which functions are planned but not yet implemented

What we learned

The main lesson was that useful AI for construction is not only about generating an intelligent answer.

A trustworthy professional workflow also requires:

  • Reliable data acquisition
  • Visible provenance
  • Deterministic business rules
  • Clear AI boundaries
  • Safe failure states
  • Reviewable evidence
  • Honest metrics
  • Human approval

We learned that AI becomes more useful when it supports an estimator’s judgment instead of attempting to replace it.

We also learned that testing with real public data is essential. Several important problems were not visible in synthetic fixtures or code review and appeared only when the workflow was exercised against real public-source records.

Finally, we learned that transparency about limitations makes a product stronger.

BuildMatch does not claim:

  • That every public source is always available
  • That every AI assessment is correct
  • That AI replaces professional judgment
  • That the current version completes the entire estimating process

What's next for BuildMatch BC — Tender-to-Bid Copilot

The next step is a structured pilot with construction estimators.

We want to measure:

  • Time saved during weekly opportunity review
  • Percentage of relevant projects surfaced
  • False-positive and false-negative rates
  • Agreement between deterministic and AI recommendations
  • Estimator corrections during human review
  • Which evidence most influences bid/no-bid decisions

Planned future stages include:

  • A hosted multi-user BuildMatch service
  • Additional municipal and provincial sources
  • Team assignments and notifications
  • Feedback-driven contractor profiles
  • Tender-document classification and scope extraction
  • Structured bid-item and quantity workflows
  • Bluebeam-assisted takeoff review
  • Controlled HeavyBid integration
  • Connections between opportunity discovery, estimating, and contractor matching

Our long-term goal is not to automate estimators out of the process.

It is to remove repetitive searching, organizing, and first-pass review so construction professionals can spend more time evaluating risk, pricing work, and making better decisions.

Built With

Share this project:

Updates