A trade contractor's business runs on about 40 distinct functions, from finding bid invitations to closing the books at year-end. BidReady covers four of them — the four that decide whether the rest of the year is profitable. They all sit in the Pre-Award (Bid Pursuit) phase: the work between an invitation landing in your inbox and a signed contract on your desk.
Win this phase and the rest of the business has fuel. Lose it and no amount of field discipline saves the year.
This is what we ship today, and what we're shipping next, in each of the four.
Classify what comes in. Decide what's worth opening.
A small trade shop's bid pipeline is an inbox. Invitations arrive from general contractors, plan rooms, and portals all day long — interspersed with newsletters, marketing, auto-replies, and project-already-running follow-ups. The contractor who misses 40–60% of legitimate invitations doesn't have a sales problem. They have a triage problem.
We ingest inbound messages from Microsoft Graph, Gmail (IMAP), SendGrid, and SMS via Twilio into a single staging table. A fast language model classifies every message into one of three buckets — new_bid, project_inbound, or irrelevant — with a confidence score, a one-line reason, and a detected trade signal. We compute a 0.0–1.0 trade-match score against the contractor's declared trades, so an electrical shop sees electrical invites at the top of the feed and a plumbing invite from a confused GC drops to the bottom.
We deduplicate by sender fingerprint, suppress repeat-noise senders (with a poisoning cap so a malicious sender can't blow up the suppressor), and surface the result as a "detected bid" card in the contractor's feed. Cards have a 5-second undo on dismiss, a reassign action when the classifier guesses the wrong project, and an auto-dismissed tray to recover anything the system suppressed by mistake.
Plan rooms (Dodge, ConstructConnect, BuildingConnected) push volume. They do not triage. Every invitation looks the same — the contractor still has to read each one. Small shops triage manually over morning coffee, which is exactly why so many bids never get opened.
BidReady reads the package and tells you what's in it. That changes the inbox from a pile to a queue.
A working contractor spends 30–60 minutes a day sorting bid email. We give that time back. More importantly, we catch the winnable bids that would have been buried under irrelevant noise — that's revenue the shop wasn't capturing. And we kill the inverse mistake too: estimating hours spent on bids that never had a chance.
The next layer is a real chase / no-chase recommendation that factors capacity, project value band, due-date pressure, and the contractor's historical hit rate with the GC sending the invitation. Today we tell you what kind of bid this is. Soon we will tell you whether you should pursue it.
We're also wiring in direct GC-portal connectors (BuildingConnected, BidExpress) so invitations arrive without an email round-trip.
Read the drawings. Read the specs. Count everything. Price it.
This is the function most contractors think of when they think about bid software. It's also the one where contractors lose the most money — to forgotten line items, mis-counted fixtures, and "good enough" assumptions that turned out not to be.
We parse the bid package along two parallel legs.
The spec leg uses Docling with a hierarchical chunker to read CSI-organized specification PDFs. We extract division and section numbers (CSI 26 05 13, CSI 23 09 00, and so on) directly from the heading structure, with OCR fallback for scanned PDFs.
The drawing leg uses a vision language model to read blueprints. Before we spend the LLM budget, we pre-filter by sheet number — an electrical shop ignores architectural sheets, a plumbing shop ignores fire alarm — so we're only paying to read sheets that matter to your trade. We process at 200 DPI JPEG, capped at 50 sheets, and classify each sheet by type (one-line diagram, floor plan, panel schedule, fixture schedule, fire alarm plan, etc.).
Both legs converge into a four-stage takeoff pipeline:
Each line item carries traceability back to the sheet and spec section it came from. Human edits are captured in an audit trail so corrections become training signal.
And critically: we run historical-bid RAG on every estimate. The contractor's own past bids are embedded into a pgvector index, and the takeoff generator pulls in similar prior work as reference. This is how the system gets sharper per contractor over time.
Manual takeoff in Bluebeam or PlanSwift is 8–40 hours of human attention per bid. Existing AI-takeoff startups focus on drawings only — they miss everything that lives in the specs. We fuse spec parsing and drawing analysis into one pipeline.
The historical-bid layer is the structural difference. Most tools ship the same model to every customer. Ours learns your shop's pricing, your scope language, and your assumptions, and brings that context to every new bid.
This is the biggest single time savings in the product. A bid that took two days in Bluebeam takes a couple of hours in BidReady. A small shop that could bid 50 projects a year can now bid 150 without adding estimators.
On the margin side, the system catches the items that human estimators forget under time pressure — the disconnects, the fire-alarm devices in a back room, the long-lead switchgear lead time. Those are the items that show up as margin leaks at closeout. Catching them upfront is the difference between a 6% margin and a 14% margin on the same job.
Today's rule-based estimator covers electrical (NEC). We're extending it to plumbing, HVAC, mechanical, and fire protection so the same deterministic-first, LLM-fallback structure works for any trade.
We're also closing the estimate-to-actuals loop: pulling job-cost variance from completed jobs back into the pricing layer so the system self-calibrates without anyone having to type a number.
Turn the estimate into a polished proposal the GC can sign.
Estimating ends with a number. The proposal is the document that carries that number to the GC — branded, scoped, conditioned, with inclusions and exclusions tight enough to survive contract review. Done badly, this is where the day's best estimate turns into a typo, a wrong project name, or a stale exclusion that costs you the job or the lawsuit.
We generate the proposal directly from the takeoff. A Claude tool-choice call produces structured narratives — cover letter, scope narrative, exclusions, qualifications — sized to ranges that read as professional rather than padded. The narrative engine knows the project name, the GC, the bid amount, and the contractor's credentials, because they're already in the system.
We render the narratives into a branded DOCX using the contractor's template, then convert to PDF via LibreOffice. Proposals are versioned (version number, template name, status, format, storage path, narratives JSONB) so you can submit a revision against a late addendum without overwriting the original.
The numbers in the proposal are the numbers in the takeoff. There is no re-keying step where errors can hide.
Today, most small contractors build proposals by opening last year's Word doc and editing. That's how wrong project names ride along. That's how stale exclusions about "no underground work" stay in a proposal for a fully-underground job. That's how the spec for a different building's switchgear ends up in the cover letter.
We start from a clean template and the current project's data every time. The proposal is downstream of the estimate by construction.
Two to four hours per proposal, back. More important than the time: we eliminate the category of error where the proposal's numbers don't match the estimate's numbers. That class of mistake is a margin-killer when caught in contract review, and a lawsuit when it isn't.
Versioning means a late-arriving addendum doesn't force you to risk submitting the obsolete bid.
We're building a full submission audit log — recipient, submission timestamp, file hash — so every proposal has a defensible record of what was sent, to whom, and when. This matters for protest situations and for any contractor who has ever had a GC claim "we never got your bid."
After that: direct GC-portal submission with auto-fill of the GC's bid form, and automated addendum diffing so the system knows what changed between addendum 1 and addendum 2 and updates the proposal accordingly.
Did we get it? If not, why not? And what does that tell us about the next bid?
This is the function the industry treats as optional and most small contractors skip entirely. Skipping it is why so many shops cannot tell you their win rate, cannot tell you which GCs actually award them work, and cannot tell you what they're losing on. You cannot improve what you do not measure.
Every bid in the system has a status. The status is a real state machine: draft → parsing → scope_review → estimating → proposal → submitted → won | lost → archived. Transitions are validated — you cannot mark a project "won" until it has actually been submitted. That eliminates the small but persistent class of pipeline-hygiene errors that ruins win-rate reporting.
When a bid resolves, the contractor records the outcome plus a structured loss reason: price, scope, timing, not_responsive, no_decision, or other, with an optional free-text note. Every status change publishes a BID_STATUS_CHANGED event, and an append-only audit table captures any retroactive reason corrections — useful when a "no decision" eventually becomes a "lost to lower bidder."
The reporting layer computes win rate (won / (won + lost)) for the current period and the previous period, with the percentage change between them, and a pipeline view that breaks active projects out by status. A background snapshot job refreshes per-org pipeline aggregates every 300 seconds so the dashboard never has to wait.
When win rate moves materially, the agent layer can post a proactive nudge into the contractor's feed.
The diagram tag for this function on our internal model is "Implicit" — meaning, in the industry, this function exists in name but most small shops perform zero effort on it by default. There is no bid log. There is no reason code. There is no win rate. Sales CRMs like HubSpot and Salesforce don't fit construction's bid flow.
BidReady is the bid log because BidReady is also the system that submitted the bid. The win-loss data is a side-effect of using the product, not a separate spreadsheet someone has to remember to update.
The compounding payoff. Once a contractor has six months of structured bid history in the system, the questions stop being existential ("are we making money?") and become tactical ("we're losing 60% of jobs over $200K on price — what's wrong with our pricing for that band?"). A small shop's hit rate is typically 10–25%. The difference between 12% and 22% over a year is the difference between a hiring round and a layoff round.
The next slicing layer: win rate by GC, by trade, by project value band, by geography. That's where the strategic questions get answered — "which GCs actually pick us, which ones never do, which value bands are our sweet spot."
After that, the closed loop: loss reasons feed back into the estimating layer so the pricing recalibrates automatically when "lost on price" reasons cluster, and the triage layer learns to deprioritize invitations from GCs we never win.
The longer-term goal is predictive win probability — a confidence number on every bid before you submit it, so you know whether you're swinging at a winnable pitch.
| Function | What we ship today | What's next |
|---|---|---|
| Bid Invitation Triage | Auto-classify, trade-match scoring, noise suppression, dismiss/undo | Chase/no-chase scoring with capacity and GC history; direct portal connectors |
| Estimating and Takeoff | Spec + drawing parsing, four-stage takeoff, NEC rules, historical-bid RAG | Multi-trade rule estimators; closed-loop pricing from job-cost actuals |
| Proposal Generation | AI-authored narratives, branded DOCX/PDF, versioned proposals | Full submission audit; direct portal submission; addendum diffing |
| Bid Follow-up / Win-Loss | State machine, structured reason codes, win-rate trending, agent nudges | Win rate by GC/trade/value/geo; closed loop into estimating; predictive win probability |
For honesty's sake, and because it sharpens what we do: BidReady today does not run your accounting, your payroll, your scheduling, your field reports, your safety logs, your permits, your submittals, your buyout, or your warranty work. Those are 36 of the 40 contractor functions, and they live in tools like QuickBooks Contractor, Procore, Foundation, Buildertrend, and ServiceTitan.
We don't compete with those tools. We make sure the bids that fund them are won.
Draft v1 — 2026-05-13. Numbers and time estimates are industry-typical ranges, not BidReady customer data; replace with measured customer outcomes as the install base grows.