How the Deal Score Works
Generated from the code that computes the scores — what you read here is what actually runs
- Methodology version
- v1
- Scores last computed
- 14 October 2026
- Projects scored
- 162 published of 1,043 tracked
How the Deal Score works
Every figure on this page is generated directly from the code that computes the scores, so what you read here is what actually runs. Methodology version v1.
What it is
A Deal Score is a 0–100 read on how one off-plan project compares with the others we track — above all, with the other projects in its own community. It is not a prediction and it is not advice. It is an arithmetic summary of facts developers have published, plus one thing no developer can tell you: how their project prices against its neighbours.
What we refuse to do
- We never invent a number. A project whose developer publishes no price gets no score at all — not a zero, not an estimate, not a guess from the neighbours.
- We only score what you can buy. Sold-out and handed-over projects are never scored. A buy verdict on stock nobody can buy is meaningless.
- Thin data caps the score, rather than being averaged away. A project we can see only two things about cannot reach a high score by doing well on both. See the confidence table below.
- Every pillar below lists its own weakness. Those limitations are part of the method, not footnotes to it.
The six pillars
Each pillar produces a score out of 100. The Deal Score is their weighted average — but only across the pillars we could actually compute. A project judged on four pillars is judged on those four, not penalised for the two we could not read. That is why the weights below sum to 100 but a given project may be scored on fewer.
A project must have at least 35 points of weight available or it receives no score. A verdict resting on a single pillar is not a verdict.
value — weight 30
The entry price against the median entry price of comparable projects in the same community.
| Price ÷ community median | Score |
|---|---|
| 0.4 | 100 |
| 0.7 | 90 |
| 1 | 65 |
| 1.4 | 40 |
| 2 | 20 |
| 3 | 5 |
Values between two rows are interpolated in a straight line; values beyond either end are clamped.
Limitation. This compares ENTRY prices. A tower whose smallest unit is a three-bedroom will read expensive against one selling studios. Where enough comparables share an entry unit class we compare within it; where they do not, the project is marked unit-mix unadjusted.
payment — weight 20
The share of the purchase price still unpaid at handover — how much cash the plan leaves in your pocket during construction.
| % due at or after handover | Score |
|---|---|
| 20 | 25 |
| 30 | 45 |
| 40 | 60 |
| 50 | 75 |
| 60 | 85 |
| 80 | 100 |
Values between two rows are interpolated in a straight line; values beyond either end are clamped.
Limitation. Only plans published as explicit percentages can be scored. A plan advertised as “1% monthly” is shown as the developer wrote it and left unscored — we do not guess a structure out of prose. A plan that counts its instalments in months from the booking date is reported as published and not scored: how much of it falls before or after handover depends on when a buyer books, and the score never assumes a booking date.
developer — weight 15
How much the developer has brought to market, adjusted by how much of their published stock has sold out — where their own site says so.
| Projects published | Score |
|---|---|
| 1 | 20 |
| 5 | 40 |
| 15 | 60 |
| 40 | 80 |
| 100 | 95 |
Values between two rows are interpolated in a straight line; values beyond either end are clamped.
Limitation. Portfolio size is a proxy for scale, not for build quality and not for delivery record. It measures how much a developer publishes. Sell-through can only be read for developers whose own site labels sold-out stock — six of the twenty-one we track.
timeline — weight 15
How long until handover. Nearer completion means less construction risk.
| Quarters to handover | Score |
|---|---|
| 0 | 95 |
| 4 | 85 |
| 8 | 70 |
| 12 | 55 |
| 16 | 40 |
| 20 | 25 |
Values between two rows are interpolated in a straight line; values beyond either end are clamped.
Limitation. A nearer handover is treated as better. A longer horizon spreads the payment plan further, which some buyers prefer — this pillar does not reward that.
momentum — weight 10
How the published price has moved since we started tracking it, from our own append-only price history.
| Price change % | Score |
|---|---|
| -10 | 45 |
| 0 | 60 |
| 5 | 75 |
| 10 | 88 |
| 20 | 100 |
Values between two rows are interpolated in a straight line; values beyond either end are clamped.
Limitation. This rests on price changes we have observed ourselves. A project we have only seen once has no trend, and we report that as no trend rather than as stability.
liquidity — weight 10
How actively the community actually trades, from Dubai Land Department transaction records.
No anchors — this pillar is declared but not yet in service.
Values between two rows are interpolated in a straight line; values beyond either end are clamped.
Limitation. Not yet in service. No project receives a liquidity score today, and none of the scores above depend on one.
Confidence
Confidence describes how much of a project we could actually see. It sets a ceiling on the score — so a project with excellent numbers but very little published information cannot outrank a project we know thoroughly.
| Confidence | We could see | Effect |
|---|---|---|
| High | A price, at least 8 comparable prices in the same community, a payment plan or a handover date, and a developer with 10+ published projects | Full range available |
| Medium | A price and at least 5 comparable prices | Score is capped |
| Low | A price, but too few comparable projects to judge it against | Score is capped lower |
| Insufficient | No published price, or too little else to go on | No score |
| Not applicable | The project is not currently selling | No score |
We publish the confidence level beside every score. We do not publish the cap value itself — the confidence badge is the honest summary of it.
Comparable sets
A project’s price is judged against other published prices in the same community, and only when there are at least 5 of them. Where enough of those projects share the same entry unit type (a community with five or more studio-entry towers, say) we compare within that type; otherwise we compare against the community as a whole and mark the project unit-mix unadjusted.
There is no city-wide fallback. Comparing a Jumeirah Village Circle studio against an all-Dubai median is not a comparison, and we would rather say we cannot judge a project than produce a confident wrong answer.
Community medians are rounded to the nearest AED 25,000 before use. That is deliberate: without it, one new project appearing in a community would nudge the score of every other project there, and scores would drift daily on no real news.
What makes a score move
A score changes when, and only when, one of its inputs changes:
- the developer changes the published price
- the developer publishes, or changes, a payment plan or handover date
- the project changes status
- enough prices in its community move to shift the community median past a rounding step
- the developer’s published portfolio or sold-out count changes
- the methodology version changes — which is a deliberate, published event
We recompute every score once a day. On a day when nothing above happened, every score is byte-for-byte identical to yesterday, because we compare a fingerprint of the inputs and skip the write entirely. We keep a history row only when a score or its confidence actually moved.
Where the data comes from
Every fact behind a score is read from the developer’s own public website and carries the URL it came from. We do not use property portals, aggregators, or anything behind a login. Where a developer publishes nothing on a subject, we record nothing — and the score reflects that absence rather than papering over it.
Where a developer’s page states the same fact twice and the two disagree — the project’s own structured record and a label printed on the page — we use the structured record, and keep the label only for pages that carry no record.
Dubai Land Department transaction data is not yet part of the score. The liquidity pillar above is reserved for it and currently contributes to no project.
Generated from src/enrich/methodology.ts by npm run enrich:methodology. Do not edit this file by hand.