Most "construction estimating software" was built for GCs and adapted, loosely, for subs. For a waterproofing contractor, that usually means a general-purpose takeoff tool bolted to a unit-cost database that has never heard of a fluid-applied membrane, plus an export button to Excel — where the real estimating still happens.
If you're evaluating software in 2026, here's what actually separates a platform that will change how you bid from one that becomes an expensive PDF viewer.
1. Does it know your systems, or just "waterproofing"?
Deck coatings, hot rubberized asphalt, bentonite, sheet-applied membranes, crystalline treatments, injection grouting, air barriers, below-slab vapor barriers — each of these prices differently. Coverage varies by coat and substrate. Packaging matters (you buy pails and rolls, not gallons and square feet). Waste behaves differently on a 40,000 SF podium than on a 400 SF elevator pit.
Ask the vendor to show you a worksheet for a specific system you install — with its coats, primers, aggregates, and accessories — not a generic assembly. If the demo can't price a real system from a manufacturer you use, the software doesn't know your trade.
2. Are the rates yours, and are they live?
An estimating tool that ships with "industry average" pricing is a liability. Your supplier pricing, your negotiated discounts, your labor rates, your crew structures — those are the estimate. Two questions to ask:
- When a material price changes, do all open estimates reflect it — or do you re-key it estimate by estimate?
- Can labor be priced from your production rates per system, not a national database?
3. Margin-based pricing, not markup guesswork
There's a difference between "add 30% to cost" and "hit 38% gross margin on this scope." Good software lets you set a target gross margin per scope and back-calculates the sell price — including travel, mobilizations, and minimum-labor rules — so the number you submit is the number your P&L needs.
4. Does the estimate go anywhere?
The estimate is the middle of a longer chain: a CRM opportunity before it, a proposal after it, then an SOV, submittals, RFIs, daily logs, and closeout if you win. Every re-keying step between those stages is an error waiting to happen. Look for:
- Proposals generated from the estimate, on your letterhead, that stay in sync when the number changes.
- SOVs built from estimate scopes — so billing matches what was bid.
- Submittal packages driven by the products you actually estimated.
5. AI that assists — with your data, under your control
AI is genuinely useful for drafting RFI language, summarizing project status, and answering "how many days is this scope at our production rate?" It is not a substitute for an estimator's judgment. Evaluate AI features on three axes:
- Grounding: does it answer from your project's data and cite where the number came from?
- Control: does anything get sent without a human approving it? (It shouldn't.)
- Data terms: is your customer data used to train public models? (Read the privacy policy — it should say no.)
Also worth watching: platforms adding MCP (Model Context Protocol) endpoints, which let AI agents you already use — like Claude or ChatGPT — work inside your estimating workspace with permissions you control.
6. Customization is a feature, not a phase-two promise
No two waterproofing contractors price identically. If the software can't be configured around your material catalog, your labor model, and your proposal language during onboarding, you'll bend your process around the tool — which is how tools end up abandoned by March.
The short version
- Demo a real system you install, end to end.
- Insist on your rates, live, in one place.
- Price to gross margin, not markup folklore.
- Follow the estimate through proposal, SOV, and submittals.
- Treat AI as a drafting assistant with citations, not an oracle.
That's the standard we built Division 7 Estimating against — and the demo we're happy to give. Schedule one, and bring your hardest scope.