baxie is a multi-tenant SaaS for residential general contractors, in paid 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.
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, closeout, on one system with the cost data joined up.
The buyer is a situation, not a revenue band. 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 surface at baxiehq.com. App at app.baxiehq.com. Paid beta, currently on v0.20.0.
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.
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 rather than mis-mapped into something that looks right.
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.
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 rather than complete.
The known limitation, because it matters more than the feature list. A 35-by-24 inch plan sheet gets rasterized at roughly 74 DPI before the model sees it, which puts 3/32-inch printed dimension text at about seven pixels tall. The model frequently cannot read the dimension strings the prompt asks it to read, and says so. That is the dominant failure mode, it is the reason the review gate exists, and it is the problem the next architecture has to solve rather than route around.
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.
baxie is the reference implementation. These are the code paths I maintain, which is why moving one onto a client stack is a port rather than a research project.
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.
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, not code, so a workflow swaps models when pricing moves. This is the argument a CFO signs off on.
The markup engine throws rather than return 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 is skipped constantly.
AI consultants pitch frameworks. A smaller group ships demos. Very few maintain a production system where a wrong number reaches a contractor's price, which is the situation that 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.
baxiehq.com is the live product. If the patterns map to your stack, book a call and I will tell you which ones are worth porting and which are not.
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 rather than 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.
No, and I will not invent one. The only measurement is an internal baseline on a single plan set and it was poor. Building a dataset worth quoting is the current work. The guardrails are designed for exactly the state where the number is not yet known.
Because a 35-by-24 inch plan sheet gets rasterized at roughly 74 DPI, which puts printed dimension text at about seven pixels tall. The model frequently cannot read the dimensions it is asked to read. The gate exists because of a limitation I can measure, not as a formality.