Telling a language model to “value an apartment” is a quick way to get a well-mannered number. It may come with a confident explanation, a list of factors, and almost no verifiable foundation.
In LiveDXB Analytics, I used a separate calculation engine. It takes transactions from the database, selects comparables, calculates the distribution of price per square foot, and compares the asking price with it. AI commentary comes afterwards. TypeScript code produces the numerical result.
But it is easy to relax too soon. A program can flawlessly calculate the median of badly matched apartments.
How the calculation works
The interface uses React; the API uses Hono in a Cloudflare Worker. D1 stores normalised data and check results; R2 holds original uploads. A result has input parameters, a timestamp, and a methodology version.
The engine identifies the median and quartiles and filters statistical outliers using the interquartile range. It compares the property price with the resulting band. If fewer than three initial comparables are available, it returns INSUFFICIENT DATA.
The archived valuation form already has a fictional property selected. You can inspect its inputs and the available path to a result. This is a standalone demo, not a query against the current market.
Valuation inputs
Archived interface · demo data
This is a useful way to decline. The interface keeps working without pretending that every button press must produce a price.
This screen shows a prepared demonstration result. It illustrates the calculation’s presentation, but its figures do not establish the market price of a real apartment.
Valuation result
Archived interface · demo data
Which transactions enter the comparison
The current selection uses area tolerances of 18 and 30 percent. Transactions are sorted by date, but the query has no explicit calendar cutoff. The earlier methodology described 180/365-day windows and 15/25-percent tolerances; the code does not yet match it.
Broader matching also relaxes similarity conditions. That can find data, but it changes what the result means. Older and less similar transactions do not become precise comparables simply because there are enough of them for a calculation.
That is why I do not call the system a guaranteed accurate valuation or repeat the early “zero hallucinations” promise. A separate algorithm makes the arithmetic reproducible. Sample quality, source freshness, and suitability of the conclusion require their own checks.
The product I want to build from this
A tool that shows why these transactions were selected, which constraints were relaxed, and where confidence ends. The next improvements should begin with reconciling code and methodology, checking freshness, and validating comparable quality. Another elegant paragraph from the model can wait.
This project should not be confused with the paused Comps Engine inside the broker CRM. It has its own implementation; code and a previous deployment do not prove that the market database is currently complete.
LiveDXB Analytics has its own calculation engine. It is a separate implementation after Comps Engine, with its own data and methodology limits. Reproducible calculation lets you check the arithmetic; it does not replace checking the sample’s completeness and freshness.
Related stories: Comps Engine exploration · Mortgage calculator.
@nevsky_alexander
On Instagram: Dubai beyond the postcard — family, the city, discoveries and life between projects. On Threads: thinking out loud about design and AI. On YouTube: videos that need more room than a story. Follow me wherever you feel at home, and let’s keep in touch