LV-Pilot
Reads a Bill of Quantities, identifies the trades in it, sends subcontractor requests by email and compares the answers. One weekend, as a case study rather than a product — and it has run the whole chain end to end once.
Built with one other person over a single weekend, after a working session with a site manager who does this job by hand.
The problem, before any technology
None of this was invented at a desk. A site manager I know sat down with us in May 2026 and we went through his working day until one process was left: narrow enough to build in a weekend, broad enough to be worth building.
Every enquiry for a new build arrives with a Bill of Quantities — the document listing every item of work to be priced. He reads it, works out which trades the job needs, writes to the subcontractors for each one separately, collects what comes back, compares it, and decides. Manual, repetitive, easy to get wrong, and by his own account several hours per project.
One thing he said decided everything below: subcontractors answer by email, and the trade accepts no other tool. So a portal was never an option — and the hard half of this is not sending, it is reading what comes back.
Scope, stated up front
One weekend, one workflow, two of us. The weekend was not a method — it was the time we both had during term, and everything else was cut to fit it. The only real material is one Bill of Quantities and a set of old enquiry emails, which is what the extraction was tuned against.
The weekend is about 95% of it. One morning in July 2026 went on the landing page and two fixes, and the end-to-end run that August was a walkthrough of what the weekend had already built, not a second build phase.
Two candidates came out of that conversation and only one was built. The other was an AI knowledge base for onboarding, dropped the same day as too generic to beat the tools that already do it — and building both was dropped with it.
The pipeline, stage by stage
- Ingest
- The Bill of Quantities is uploaded and turned into text before it is ever a prompt. Claude’s document endpoint accepts PDF only and these arrive as Word files; the first extractor spent the whole CPU budget of its function, so it became an unzip and an XML strip.
- Recognition
- Every position is extracted with its number, description, quantity and unit — into a tree of main groups, subgroups and positions, the shape a Bill of Quantities is written in. A real one is too long for a single call and the analysis runs against a hard wall-clock limit, so it goes asynchronously and in chunks.
- Matching
- Each subgroup gets a trade, matched against the trades each subcontractor is on file for; one email per pairing. The trade sits on the subgroup, not the main group above it — “shell construction” is not a trade, “01.02 concrete work” is. And nothing goes out on its own: the drafts wait for the site manager, who is accountable for what leaves in his name.
- Dispatch
- Confirmed drafts go out as ordinary email, each carrying a token in its reply address. The subcontractor hits reply and never sees the system, so the reply has to identify itself: no portal, no login, nothing to quote back.
- Comparison
- Inbound replies arrive at a webhook, are matched back by that token and classified — priced, unpriced, question, refusal — so the answers for one trade sit side by side. This was the risk logged a week before the build: real replies are prose, or a PDF, or “call me”, and anything the classifier is unsure of goes to the site manager with the mail attached rather than a guess.
None of those five is specific to construction: they are what a document-heavy process decomposes into, and a Bill of Quantities is one case of it. An incoming invoice is another, and so are a quotation to check and a tender to compare.
On 4 August 2026 the whole chain ran once against the live instance: four requests out inside a second, the first reply back and classified 81 seconds later. One read, in full, „Wir nehmen an Gesamtkosten 50 000 euro“, and came back as a priced offer of 50,000. Every request went to our own mailbox: this is the classifier on unformatted text, not the trade answering.
What’s missing, and what it would cost
What is missing is not architecture, it is the list you work through when a prototype becomes a tool. A sender profile, so the signature stops going out with its placeholders unfilled. The comparison tiles checked against a real case before they go back on the screen. The analysis on a queue with real retries instead of inside a function’s time budget, so a long document cannot come back short. The trade list in the prompt, so a subgroup gets the most specific match rather than the nearest.
That is another weekend to a few days. The estimate is ours and it is not validated — but it is not a guess either: every item on the list is named, bounded, and independent of the rest.
Running it costs close to nothing: free tiers throughout, and an estimated €10 of model usage across the whole weekend and every test since. So whether a tool like this is worth having never turns on what it costs to run — it turns on whether it saves the hours the manual round takes, and that has not been measured.
And measuring it is not an engineering question: whether a site manager, given a screen of drafts he still has to check, sends them — or goes back to writing five emails himself.
Nobody has put it in front of him yet, and that is the first thing I would do. The session would time his manual round as a baseline, then run the pipeline against a Bill of Quantities he has already worked through by hand, so that every correction he makes to its drafts and its trades can be counted against work whose right answer is already known. What decides it is his own answer on whether he would have sent them.