baxie is a multi-tenant SaaS for residential general contractors, in beta. Vision extraction on architectural plan sets, multi-model routing, a human review gate enforced in code, and a markup engine that refuses to guess. This page says what runs, what does not, and what I will not claim about it.
Want the client version? Read a diagnostic example.
A general contractor prices a job, wins it, builds it, and finds out months later whether it made money. The estimate lives in one place, the actual costs in another, and nothing connects them while the job is still running. baxie closes that gap: CRM, estimating, proposals, budgeting, scheduling, field logs, change orders, and closeout, on one system with the cost data joined up.
The buyer is defined by a situation. A contractor who escaped spreadsheets or bounced off Procore and Buildertrend, who prices from memory, and who cannot tell you today which scope on which job is running over. California first, because the production cost library is built on California labor and county permitting.
What it does about margin, stated precisely. baxie computes a markup multiplier from the contractor's own overhead and profit targets, adjusts it by job size so a small job is not asked to carry the same overhead as a large one, and compares estimate to actual per budget line as field logs and expenses come in. When gross profit on a quote falls below what that job needs to contribute toward annual overhead, it raises a flag. It does not block the quote and it does not price the job for you. baxie gives a contractor visibility into margin while there is still time to act on it. It cannot protect margin, and any tool telling you otherwise is selling you something.
Public site at baxiehq.com. The app runs at app.baxiehq.com, in beta.
A contractor uploads an architectural plan set as a PDF. The current production path sends the whole set to one Claude Opus model in a single pass, so the model reasons over the full set in one context instead of page by page. It comes back with a quantity table: one row per scope and unit, carrying the quantity, which structure it belongs to, the source page and sheet revision, a confidence score, and a "show your work" breakdown whose parts have to sum to the total.
Constraint
The model can only emit scopes from a fixed list of 20, each tagged with the unit it must be measured in. The list is closed on purpose. It stops the model from inventing a scope name and from returning a count where an area is required. Anything off-list comes back null instead of mis-mapped into something that looks right.
Check
A deterministic pass checks the model's numbers against geometric primitives and against the model's own shown work, then flags outliers like roof undershoot or double-counted transoms and lowers the confidence on that row. It never overwrites the number. Each flag carries a suggested alternative a human can accept.
Gate
Every AI-extracted quantity is written as pending_review and cannot enter a price until the contractor accepts it row by row. That is enforced in the data layer, not by convention. A run below 0.6 overall confidence, or one that returns nothing, is marked needs-review instead of complete.
The known limitation, because it matters more than the feature list. A full plan sheet gets squeezed into one image before the model sees it, so the smallest printed dimensions end up a few pixels tall. The model often cannot read the dimension strings the prompt asks for, and says so. That is the dominant failure mode and the reason the review gate exists. Since September, a second read zooms into the regions the first pass was unsure of and sends them at full resolution, so small text gets the whole image. Whether that closes the gap is part of the accuracy report.
If you are evaluating me to run your AI program, the useful signal is what I say about my own system when the numbers are not flattering. So, plainly:
None of that stops the system from being useful to the contractors running it, because the guardrails were designed for exactly this state. It does stop me from putting a percentage on a slide before the test set can back it.
The method is public before the result is. Each plan set in the test is also taken off by hand, and baxie's takeoff is scored against it on two numbers. Neither gets blended into one percentage, because scope varies too much from job to job for a single number to mean anything.
| Measure | What it checks | Result |
|---|---|---|
| Scopes found | Of the scopes on the hand-checked takeoff, the share baxie also found. | Report in progress |
| Quantities in band | Of the quantities it found, the share within 15% on areas and lengths, or within one on counts. | Report in progress |
| Plan sets in the test | Real residential plan sets: ADUs, a deck, bid sets, and full jobs. | 1 of 8 fully checked |
How the 15% band compares. Contractors already live with ranges. A bid-stage estimate is expected to land within about 15% under to 20% over the final cost. Remodelers carry 10 to 20% contingency for what a plan set cannot show, and older homes and gut rebuilds carry 25 to 35%. Change orders draw from that buffer.
| Reference | Typical range |
|---|---|
| Bid-stage estimate (AACE 56R-08, Class 2) | 15% under to 20% over |
| Remodel contingency | 10% to 20% |
| Older homes and gut rebuilds, contingency | 25% to 35% |
| baxie quantity test band | 15% on areas and lengths, one on counts |
Contingency covers cost surprises. The takeoff test measures something narrower: whether the quantities read off the plans match a careful human count. The band sits inside the range a bid-stage estimate is expected to hit. That is the test, not the result. When the report is in, the first table says how many quantities landed inside it, and which plan sets missed.
baxie is the reference implementation. These are code paths I maintain, which is why moving one onto a client stack is a port and not a research project. They map to the build types in every plan I write: plain code where a rule does the job, a model where it takes judgment, and human review where a mistake costs more than the time saved.
Document intake
Plan sets and receipts both land as structured candidates a human confirms. The receipt reader prefills a pending expense with vendor, date, and total, and never confirms money on its own. Below its confidence floor it touches no money fields at all. The same shape fits legal redlines, claims intake, and lease ingestion.
Cost control
Opus where the reasoning is hard, Sonnet by default, Haiku for high-frequency routine calls where latency and cost beat ceiling. Model choice is configuration, so a workflow swaps models when pricing moves without a code change. This is the argument a CFO signs off on.
Refusal
The markup engine throws instead of returning a nonsense multiplier when overhead plus profit reaches 100% or a split does not sum. Estimate generation hard-fails for an org that has not set its markup, instead of shipping a raw-cost draft that looks like a real price. Refusing is a feature.
Documents arriving from outside are treated as untrusted input. Text pulled out of a PDF is sanitized before it reaches any downstream prompt, and no extracted field has a path to act as an instruction. That is table stakes for any document pipeline touching money, and it gets skipped constantly.
Plenty of AI consultants pitch frameworks, and a smaller group ships demos. Very few maintain a production system where a wrong number reaches a contractor's price. That situation teaches you where the guardrails have to go. Every pattern on this page exists because something in baxie needed it, and the failure modes I design around in a client engagement are ones I have had in my own logs.
baxie is the reference implementation. Vision extraction on architectural plan sets, a receipt reader that prefills but never confirms money, and multi-model routing all run inside the stack that was already there. Nothing about that pattern is construction-specific.
Buy anything that is not the thing you are differentiated on, and build where your own data is the advantage. In baxie the cost engine is built because a contractor's overhead math is the product, and the models are bought because nobody wins by training their own.
A human acceptance gate enforced in the data layer, not only the interface. A confidence floor below which the system declines to act. A deterministic check that flags the model's outliers without overwriting them. And sanitization of any text pulled out of an uploaded document before it reaches another prompt.
Not published yet. The test set is eight real plan sets scored against hand-checked takeoffs: scope found, unit correct, and quantity within 15% on areas and lengths or within one on counts. One is fully checked today. The report goes on this page when the set is complete, failures included.
Because a full plan sheet gets squeezed into one image, which leaves the smallest printed dimensions a few pixels tall. The model often cannot read the dimensions it is asked to read. A second read now zooms into the unsure regions at full resolution, and the gate stays until the accuracy report shows that is enough.
If the patterns map to your stack, I will tell you which ones are worth porting and which are not.
Book 30 minutes with EdwinNot ready to talk? Score your AI program first. Twelve questions, about four minutes, scored breakdown by email.