TerraQuotes

Founder and sole developer: I did the research, the product design, the Python parcel pipeline, and the application code. TerraQuotes tells you what landscaping your yard would cost, starting from your address. You type it in, pick your house off a list, and see what monthly upkeep runs. The number comes from the size of your lot with the buildings subtracted, which the county already publishes and gives away free. Three contractors use it today, and it is in production with money behind it.

I built a working demo in five months. The hard part was never showing a buyer a range of numbers. It was resisting the urge to build a massive DIY landscape design tool, and keeping laser focus on predicting which prices convert.

To learn that I need to know which estimates closed and which did not, and that lives in the landscaper’s own systems rather than mine: their invoices in QuickBooks, their deals in a CRM. A lost estimate only reaches me if someone inside their company turns on a setting I cannot see.

I had to proceed as if I would never obtain access to paid invoices, and built for that. The CRM as an adapter to QuickBooks exports, so an estimate could be compared to the invoice it became. Data modeling was never the problem; access to real volume was. And 978 hand-entered rows will not train a win-probability model: the gate is 75 wins and 225 losses before any training, and today it stands at 6 and 49.

I start from the assumption that I am wrong. Work is registered as a hypothesis with its null stated first, and it does not proceed until that null is rejected. I grade them by how bad it is if I am wrong and how much a user gains if I am right, and each is written down before the design, so the roadmap falls out of the ranking.

The riskiest hypothesis was that a free source of parcel sizes existed at all, and was good enough to price from. The whole product depended on it, and no national API served one. St. Louis published its own, land and building square footage both, and gave it away. The Python pipeline that turns that into a searchable address index is the part the patent claims, and it is what let the rest of the product start. The application is pending: the archive holds the specification, the claims, seven figures, and a mapping from each claim to the code that implements it. Pending is not granted, and no claim here rests on it having been.

Delivery runs from a backlog of specifications under an LLM-led protocol, so every feature is designed with its test suite first and verification is settled before code reaches production. Invalidation is ongoing: before each demo I build a field guide out of the design history file, and I run field research with every release.

H-156 was registered with its null stated alongside it, so the result had somewhere to land if the loop did nothing: “There is no meaningful improvement in estimate accuracy from the ML training loop.” The alternative was that feeding real outcomes back would close the gap between the estimate and what the job finally sold for by 15 to 25% within six months. If the loop ran and the gap did not move, the null stands and the pipeline is expensive plumbing.

Neither happened. The comparison the null and the alternative both depend on turned out to be arithmetic between two different units: the retired columns mixed a monthly figure with two one-time figures on 215 of 347 historical rows, with nothing to tell them apart. It was withdrawn before either could be scored. A null that cannot be tested is not the same as a null that holds, and the registry says which of the two this is.

What replaced it is not another guess at a number. The 15 to 25% was chosen, and the register calls it aspirational; the gate the model now answers to is derived. A power simulation registered on 2026-07-14 fixes the cohort before any training, at 75 won and 225 lost resolved outcomes, and states in advance the condition under which the model is not worth building at all: AUC below 0.60 at around four hundred. The measurement is a BigQuery view written before the rows exist rather than a query composed once the answer is visible. Today the gate stands at 49 losses against 225 and six wins against 75, with no usable won rows yet.

The machinery around it works. A model may move a price only inside its documented limits, and that path has been exercised in production. What is not settled is whether the losses arrive at all: the open action on the cohort review is to confirm that lost and abandoned deals are landing from both contractors. If they are not, the negative class is being dropped at the source, and nothing decided later recovers a loss nobody wrote down. That is the part I do not control, and it is the part the model is waiting on.