Company profile · 2 min read
Piper: connected preconstruction workflows for general contractors
Piper describes an AI operating system for preconstruction that keeps project context attached to drawings, specifications, quotes and estimates.
Cofounder of Lazyweb (a16z Speedrun). Previously grew subscriptions and built native ads at Duolingo. Writes First1000 (90,000+ subscribers).
Published · Updated
Piper connects construction project documents and company knowledge to scope, bid-leveling and estimate-review workflows.
What it does
The company homepage says Piper connects drawings, specifications, addenda, quotes, estimates and company knowledge, with findings linked to their source. Its use-case page frames each workflow around an actual preconstruction job rather than a generic prompt.
Buyer and task
General-contractor preconstruction teams doing scope, bid leveling and estimate review across large project files.
Workflow boundaries
No pricing or project outcome is documented. The workflow claims are sourced product positioning.
What I would ask
Ask which source documents are authoritative, how addenda change prior analysis, and where a human estimator must approve a finding.
Why it fits
Piper’s distinction is that it treats preconstruction as a connected process, not a document-chat window. The homepage names drawings, specifications, addenda, quotes, schedules, spreadsheets, historical costs, standards and lessons learned as inputs to one evolving project understanding. The use-case page turns that into specific jobs: generate source-backed trade scopes, level bids against intended scope, review the final estimate and run a survey that preserves what the team learned.
This is valuable where a late addendum or a hidden exclusion can change the carry, schedule or margin. A general contractor can start with one project and ask whether Piper keeps each requirement linked to its source, carries changes through the affected workflow and focuses senior attention on the unresolved judgment. The company’s outcome language is a product promise; the checked public pages do not document pricing or project savings.
The first proof point should be an estimate with known scope gaps and stale decisions. Ask which document wins when sources disagree, how a reviewer sees the evidence behind a finding and what is written back to the team’s existing process. The useful boundary is decision support for preconstruction, not autonomous bid approval.
Quick facts
| Field | Sourced detail |
|---|---|
| Buyer | General-contractor preconstruction teams |
| Inputs | Drawings, specifications, addenda, quotes, estimates and company knowledge |
| Workflows | Scope generation, bid leveling, final bid review and surveys |
| Pricing and outcomes | Not documented in the checked public pages |
Sources checked
official Speedrun profile · company homepage · source page
Sources checked — September 20, 2026.
About the author
Cofounder of Lazyweb (a16z Speedrun). Previously grew subscriptions and built native ads at Duolingo. Writes First1000 (90,000+ subscribers).
I cofound Lazyweb and publish Mudpie. This is an owner-written publication, not an independent testing organization. Research notes distinguish observations, sourced reporting and editorial judgment.
First1000 ↗ · X ↗