FirefindAI is the detection engine inside Tender-up, our estimating platform for fire-protection, electrical and security contractors. It reads a set of construction drawings and turns them into the counts an estimator needs to price a tender. This is a case study in hybrid AI: a computer-vision model does what vision models are good at, and Claude does what language models are good at. Neither could do the job alone.
We built it for ourselves first. Two of AIconsult-it's founders run fire-protection and construction businesses, so the estimating problem below is one we lived with before we automated it.
The problem: tenders are won and lost on the count
A fire-protection tender starts with drawings: floor plans dense with sprinkler heads, detectors, sounders, call points, extinguishers, hydrants and pipe runs. Before anyone can price the job, someone has to count every symbol on every sheet, by hand, with a highlighter and a clicker.
On a multi-storey building that is hours of an experienced estimator's time per tender, and it is the least valuable thing they do. Miss a dozen heads on one level and the quote is wrong. Take too long and the tender closes. Every contractor we spoke to had the same two failure modes: the count was slow, or the count was wrong.
Why one model was never going to be enough
The obvious first attempt is to point a large multimodal model at a drawing and ask "how many sprinkler heads?". It does not work well enough to price a job on. A drawing sheet is a wall of tiny, near-identical glyphs; a language model reasons well but counts poorly, and it cannot tell you where each symbol sits.
The opposite attempt, pure computer vision, counts beautifully but understands nothing. It cannot read the legend that says this project draws a concealed head one way and an exposed head another. It cannot notice that a "detector" in a car park is probably a heat detector, not smoke. It cannot explain itself to the estimator.
So FirefindAI is deliberately two engines with a human in between.
What the estimator sees
The contractor uploads the tender drawings. FirefindAI does the counting and Claude does the reading, and what comes back is a take-off laid out on the drawing itself: every detection shown where it was found, the doubtful items flagged, totals per level and per system already written up. The estimator accepts, corrects or adds, and only then do the confirmed counts flow into Tender-up's costing catalogue to become a priced tender. Nothing is priced that a person has not looked at.
The model keeps improving because the estimators' corrections feed back into it. How we do that, and how the two engines divide the work in detail, is the part we keep to ourselves.
What Claude is and is not trusted with
The division of labour matters, so we are precise about it:
- Claude does not count. Counting is the vision model's job. Claude works from the detection list, not from pixels.
- Claude does not price. Rates live in the costing catalogue, maintained by estimators. Claude never invents a number.
- Claude reads, reconciles and explains. Legends, notes, naming conventions, per-level totals, and a plain-English summary of what was found and what looks uncertain. That is language work, and it is where a language model earns its place.
- A person signs off every take-off. The system is built so that review is faster than counting, never so that review is skipped.
Results
The honest outcome is a change in the estimator's job rather than a headline number: the hours spent counting symbols become minutes spent reviewing a take-off that is already laid out on the drawing, with the doubtful items flagged. That review is the part that needs an experienced estimator; the counting never did.
FirefindAI runs in production inside Tender-up today, on live tenders for Australian fire-protection contractors, and it keeps getting better as more tenders go through it. We will publish measured figures once we have enough tenders through the system to state them responsibly.
What this case study shows
The pattern generalises well beyond fire protection. Any business that has a "look at this and tell me what is there" problem, whether it is drawings, photos of a job site, a scanned form or a product shelf, usually needs the same hybrid: a specialised model for perception, Claude for reasoning and explanation, and a human review step designed to be fast. That is how we build AI automation for clients, and it is the approach behind our work on automated quoting. The Claude side of this is our Claude consulting and implementation service.
We did not want an AI that estimates. We wanted an AI that does the counting so our estimators can estimate.