Construction · 4 min read · September 18, 2026
The estimating math for a renovation contractor passed its tests, and it still could not produce a number anyone should sign. The reason was underneath it: the price list. Here is what we found when we checked each input against a real estimate.
Because the math only multiplies what it is given. If the written price list covers two of a job's eleven trades, uses a commercial rate on residential work or assumes a wall height nobody confirmed, the estimate comes out clean and wrong. Write down a price per trade from real estimates before any AI drafts one.
This summer I checked the quoting engine I had built for a renovation contractor against one of their real residential estimates. The arithmetic was right: quantities in, prices times quantities, a schedule of payments out. Every test passed.
Then I checked where each number came from. That is where the estimate fell apart, and none of it was a bug a better model would fix.
The only price list on file came from one commercial job. Checked against a real residential estimate, it covered 2 of 11 trades, and no residential unit prices existed anywhere, only whole-estimate totals.
The only written price list in the system held about twenty line items, all taken from one commercial job. Laid against the residential estimate, it covered 2 of the job's 11 trades. Tile, plumbing, electrical, cabinetry, flooring prep and the rest had no written price at all. There were no residential unit prices anywhere, only totals for whole past estimates.
Three other inputs had the same problem in smaller ways. The fee rate in the code was the commercial one, applied to residential work. Three written versions of the payment schedule disagreed with each other, and only one matched a real estimate. And the wall area math assumed a ceiling height typed in as a constant that nobody at the company had ever confirmed.
| Input the estimate needs | Where it came from | What we found |
|---|---|---|
| Room quantities | The phone scan of each room, read by plain code | Read correctly on the one real job report tested |
| Unit prices per trade | About twenty line items from one commercial job | 2 of 11 trades covered; no residential unit prices |
| Fee rate | A constant in the code | The commercial rate, applied to residential jobs |
| Payment milestones | Three written versions | Only one matched a real estimate; one milestone still needs the billing lead's answer |
| Wall height | A constant in the code | Never confirmed with the person who measures |
Quantities, unit prices, rates, payment milestones and even wall height are inputs. Each one should point to a real document or a named person who confirmed it, or be flagged on the quote as unconfirmed.
The lesson I took from it: treat every number the estimate uses as an input with an owner. A quantity points to the scan. A price points to a real past estimate. A rate or a milestone points to a signed document, or to the person who owns billing and said so. Anything without a source shows on the draft quote as unconfirmed, where a person will see it.
The payment schedule is the clearest example. One milestone on the real estimate did not add up, and it would have been easy to call it a typo and pick the neat number. A real invoice suggested it might be how the company actually bills. That is the billing lead's answer to give, so the quote shows the question instead of hiding a guess.
No amount of building fills an empty price list. Two or three real residential estimates, read line by line, do. That is the company's knowledge, and the system can only be as good as what it reads.
No amount of building fills an empty price list. What fills it is two or three real residential estimates, ideally including a bathroom or tile job, read line by line into a price per trade, plus whatever the owner already knows about how each trade gets priced.
That is slower than letting a model estimate the missing trades, and much faster than rebuilding a customer's trust after a bad number. Industry surveys put about a third of construction work hours into looking for information, conflict and rework; a guessed price is how rework starts before the job does.
Pricing judgment stays human. The system can hold the list, apply it and flag what is missing; the estimator decides the number, and every estimate is approved before a customer sees it.
If your company already keeps a current price list per trade, this is not your bottleneck, and the useful work is further upstream, in how measurements reach the estimator. If it does not, start with a spreadsheet and your last three signed estimates, before any AI.
Common questions
It can produce a number, and that is the danger. Without a written price for a trade, a model fills the gap with something plausible. Keep any unpriced trade as a line a person prices until the company writes its own number down.
From your own past estimates, line by line. Two or three real residential estimates, ideally including a bathroom or tile job, give a starting list per trade. Industry cost books help as a check, but your own prices are the ones customers have already accepted.
Store it as data that can be changed, not as a fixed rule in the code, and copy it from a real signed estimate. When two documents disagree, keep the question visible on the quote until the person who owns billing answers it.
Sources
Next step
Bring one signed estimate and whatever price list you have. We will trace each number to its source and show you which trades are really priced.
Written by
Chris Moreno builds custom AI systems for business operations. His writing draws on the work behind these systems: intake, follow-up, document workflows, and the checks that keep people in control.
Published September 18, 2026 · Connect on LinkedIn
Our methodology
The approach behind this work follows the four phases of Flo OS, our operating methodology for turning messy business workflows into systems that run cleanly and compound over time.
See how we work →Related reading