The Goal
Hypothesis to test. Somewhere in a contractor’s pain list sits one or two problems where AI earns or saves a quantifiable, five-figure-plus sum per job — and that, not efficiency, is the only thing worth building first.
Starting position, stated up front:
- Edge — AI engineering: agents, LLMs, transcription, dashboards, fast prototyping.
- Gap — zero construction domain judgement.
- Known weak spot — OpenCV / computer-vision measurement (dimensions, takeoff), flagged as unsolved before any code was written.
The filter — what counts as worth building. Direct money, not effort saved.
| Build it if… | Kill it if… |
|---|---|
| Earns the contractor money (e.g. 5k → 10k) | Saves vague time or effort |
| Stops a quantifiable loss (1–2k of spec work → automated to ~20–30) | “Makes middle management’s life easier” |
| Buyer can point at the dollars | Value is hard to measure, attribute, or charge for |
Why money, not efficiency: efficiency gains are unmeasurable, unattributable, therefore unchargeable and undefendable at renewal. A tool that quietly saves twenty minutes a day gets praised, then cancelled. A tool that recovers a five-figure sum on one job has a budget behind it.
Two axes, not one ranking. A good demo ≠ a good business, so each idea is scored on more than payoff:
- Direct monetary value — earn/save, quantifiable.
- Net value, and ease to build / maintain / operationalise across a real site team.
- Top 4–5 reasons it fails.
- The homework on every space: who plays there, what they do well/badly, what users like/dislike, pricing, market size.
Goal in one line: don’t fall in love with an idea — find the one or two bets where the money is real, the failure modes are named, and adoption is survivable. First test subject: the starting menu.