How every number on this site is produced
Every figure published here is an aggregate we computed ourselves from developer-published project facts and the unit inventories those developers and their agents put into the public domain. Nothing is modelled, smoothed or estimated. If a page shows a median, there is a set of individual priced records behind it, and this page tells you exactly which records qualified, which were thrown out, and why.
The current build covers 2,924 off-plan projects, 52,882 priced unit records, 230 communities and 676 developers across the UAE, of which 2,337 projects are in Dubai. 2,270 projects carry a published payment plan schedule and 2,552 carry coordinates, so 372 do not. A further 1,087 records are buildings whose stated handover has already passed: they keep a page as delivered comparables and are counted in none of the off-plan figures above.
1. Where the data comes from
Two kinds of information go into the corpus, and we treat them very differently.
Developer-published project facts. Project name, developer, location, property types, bedroom mix, construction and sale status, scheduled handover, payment plan schedule and headline starting price are facts the developer states publicly about its own product. We record them as facts and credit the developer as the source of each one.
Unit inventories observed on public portals. The priced unit records were observed on the public, non-authenticated pages of PropertyFinder, Bayut and Reelly, which is where UAE developers and their agents publish off-plan availability. We name those portals as the place the public listings were observed. We do not present them as our data partners, and we do not republish their records. What leaves the pipeline and reaches this site is only our own aggregate over those observations. The full position is on the data policy page.
The three views of the market overlap heavily, so the corpus is a merge, not a concatenation. Candidate matches were resolved on name, developer, coordinates and unit mix, and the resulting match set went through an audited review, so a project that appears on all three portals becomes one project record rather than three. Merged records keep the union of the facts and the union of the unit inventory, which is why some projects carry both individual units and unit-type rows.
2. What counts as a priced unit record
The phrase “priced unit record” on this site means one row that carries both a price and a size, so a price per sqft can be computed from it. Those rows arrive at two different granularities, and we count both while telling you the split.
| Granularity | What one row is | Where observed | Rows in this build |
|---|---|---|---|
| Individual unit | One real, identified unit with its own asking price, its own size and usually a floor and a layout. | Reelly inventory feeds | 43,771 |
| Unit type | One layout within a project, carrying the starting price for that layout and the layout area. It represents the cheapest available unit of that type, not an average one. | PropertyFinder project pages | 9,111 |
Both go into the pooled distribution, because excluding the unit-type rows would silently delete every project that only ever published a price list. The consequence is that the pooled median leans slightly low, since starting prices sit at the bottom of their layout. Every community and developer page therefore prints how many of its records are individual units, and in this build 83% of all priced records are. Where a page is dominated by unit-type rows, read its median as a floor rather than a midpoint.
3. Plausibility filters
Public listing data contains typing errors, currency mistakes, plot areas entered as unit areas and placeholder prices. A row is admitted to the statistics only if all three of its values sit inside bounds that a real UAE residential off-plan unit can occupy.
| Field | Accepted range | Why |
|---|---|---|
| Asking price | AED 150,000 to 500,000,000 | Below the floor is a deposit or a monthly figure. Above the ceiling is a whole-tower or portfolio price. |
| Size | 150 to 60,000 sqft | Below the floor is a parking bay or a truncated number. Above the ceiling is a plot or a full floor plate. |
| Price per sqft | AED 250 to 25,000 | Catches the pairs that are individually plausible but impossible together, which is how unit mismatches show up. |
A row that fails any one of the three is excluded from every statistic on the site. In this build 68,875 raw rows were reduced to 59,806 valid ones, so 9,069 rows, about 13%, were dropped. The excluded rows are kept in the database rather than deleted, flagged invalid, so the exclusion is reproducible and reversible. Project headline starting prices are filtered separately: a stated starting price below AED 100,000 is treated as missing rather than as a price.
Two further gates sit on top of those three. A unit whose stated size is impossible for its bedroom count is flagged and excluded: for each bedroom count we take the median stated size across every valid row in the corpus and require a row to sit between 40 and 600 percent of it, which in this build catches 36 rows. That rule exists because the site’s own published maximum price per sqft used to be set by one of them, a 852 sqft six-bedroom villa priced at AED 20.2m, and by three-bedroom apartments listed at 153 sqft. And a unit belonging to a building that has already handed over is excluded, because a delivered building is not off-plan evidence. Together those two leave 52,882 rows behind every published price, 6,924 fewer than the valid count.
Prices are AED asking prices. Size is the built-up area as published for that unit or layout. Price per sqft is the price divided by that area, computed per row and never derived from a ratio of two medians.
4. Community canonicalisation
The same place is written a dozen ways across the market: JVC, JVC (Jumeirah Village Circle), Jumeirah Village Circle, Jumeirah Village. Community pages are only meaningful if all of those collapse into one. The resolution runs in a fixed order and stops at the first step that produces an answer.
- Location tree. Where a PropertyFinder-style structured location tree exists, its COMMUNITY node is taken directly, along with its CITY node and, where present, its SUBCOMMUNITY node.
- Bayut path parse. Bayut expresses location as a comma-separated path that reads from the most specific element to the emirate, for example “Tower, District, Community, Dubai”. When the final element is a UAE emirate we take it as the city, take the element before it as the community, and keep the one before that as the sub-community. If the tail is not a UAE emirate the record is an international listing and gets no community.
- Alias table. Whatever name survives the first two steps goes through a hand-maintained alias table of several hundred entries that maps abbreviations, parenthetical forms, misspellings and retired names onto one canonical name. The table also folds names that are marketing sub-districts rather than communities into their parent, and drops bare emirate names, since “Dubai” is not a community.
- Geographic nearest neighbour. A project with coordinates but no usable location string is assigned the community of the closest project that already carries a portal-labelled community, provided that neighbour is within 1.2 km. Anything further away is left unassigned rather than guessed.
Records placed by step four are flagged as inferred in the database, so their contribution can be isolated or removed. Anything still unplaced after all four steps is given no community and appears on no community page.
The emirate is taken from the location tree where the portal supplies one. Where it does not, the emirate is read off the projects that do carry one: the five nearest labelled projects vote, and the winner is taken only if the closest of them lies within 25 km. Tested by leaving each labelled project out in turn and re-deriving its emirate, that agrees with the portal 99.1 percent of the time. It replaced eight hand-drawn bounding boxes, whose Abu Dhabi rectangle began north of Abu Dhabi island and so left 35 real developments, 183 priced units among them, belonging to no emirate at all.
The 25 km ceiling is what makes that safe rather than merely confident. The source inventories reach past the UAE into Bali, Oman and Turkey, and without a distance limit a Canggu villa would be handed whichever emirate happened to be nearest across an ocean. A project no labelled UAE neighbour comes within 25 km of is treated as outside the country and dropped from the corpus before any statistic is computed, along with rows that arrive carrying a title and no developer, coordinates, units, price or handover date. The two rules togetherdiscarded 227 of 4,315 records when the rules were first applied, and a further 96 duplicate groups were merged after that, one building having reached the corpus twice under two spellings of its builder; the data policy gives the counts and what they moved.
5. Developer normalisation
Developer names are normalised with a deliberately light touch, because over-merging invents a track record that does not exist. Whitespace is collapsed, then the generic corporate and legal tail is stripped: properties, property, real estate, development, developments, developer, developers, group, holding, holdings, LLC, Ltd, Limited, PJSC, FZCO and FZ-LLC, along with any trailing punctuation. An explicit alias table then maps the remaining known variants of the major developers onto a single canonical name, including the cases where a subsidiary trades under a name the parent also uses.
On top of the alias table, names that differ only in punctuation, spacing, capitalisation, a trailing s, an ampersand written out as “and”, or a leading “The”, are collapsed onto one entity: Dar Global and Darglobal, B.N.H and BNH, H M B and HMB, ORO 24 and Oro24 were each two developers in the count until this build. That swept 91 project rows onto a canonical spelling. The old slugs redirect permanently to the new ones.
Nothing is merged on fuzzy string similarity. Two developers with similar names stay separate unless the alias table or one of those exact normalisations says otherwise. Stripping the Arabic article was tested and rejected: it collapses Al Ain into Ain. Projects with no stated developer are grouped under Unknown, which is retained in the database for completeness but never given a public page and never ranked.
6. Payment plan normalisation
Published payment plans are free-form: a plan can have three steps or fifteen, and the labelling differs by source. Every step of every published plan is mapped into one of four stage buckets, and the percentages inside each bucket are summed.
| Bucket | What lands in it |
|---|---|
| On booking | The down payment, whatever it is called, paid at reservation or contract signing. |
| During construction | Every instalment tied to a construction milestone or a calendar date before handover. |
| On handover | The amount due at handover itself. |
| Post handover | Instalments falling after the keys are given, which is the developer financing the buyer. |
The pre-handover figure quoted throughout the site is booking plus construction, in other words the share of the price a buyer has paid before receiving anything.
Plans whose four buckets do not sum to between 90 and 110 percent are excluded entirely. A plan totalling 40 percent is a partial schedule that was published incompletely, and a plan totalling 200 percent is a double-counted one. Either would drag a median without being wrong about the market. The 90 to 110 window keeps genuine plans that round oddly or carry a small fee line, and rejects the rest.
Medians are then taken stage by stage across the surviving plans, independently for each stage. That is the honest way to describe a population of plans, but it has a consequence worth stating plainly: the median booking, median construction and median handover percentages are three separate medians of three separate distributions, so they need not add to exactly 100. They describe the typical plan stage by stage, not one single real plan.
7. Payment plan discount and effective price
A headline off-plan price is quoted against a schedule that defers most of it for years, so two units at the same price are not costing the same money. The effective price is the present value of a project’s own published schedule, and the plan discount is the gap to the headline, expressed as a percentage of it. It appears on project pages, on the plan discount ranking and in the study behind it.
Every step of the plan is placed on a month timeline running from 2026-09-02. Booking sits at month zero, unless the step names a number of months from booking. Construction instalments are spread evenly across the months to the stated handover, and a plan listing several construction lines gives each one an equal consecutive slice of that window. The handover instalment sits at handover. A post-handover tail is spread across the months after it, using the length the plan states, whether that is written as months, as years or as a monthly percentage the step’s own share divides into. Steps are read by name and by position rather than by the stage label the source attaches, because that label is wrong often enough to move the answer.
Each step is then discounted at the rate below, compounded monthly, and the plan’s present value is divided by its own stated total, so a schedule that scrapes to 95 percent is not quietly cheapened by the shortfall. One minus that value is the plan discount. Applied to the project’s median asking rate it gives an effective price per sqft on the same basis.
The rate is 5.0 percent a year, and it is the buyer’s cost of money rather than a property return. AED term deposits pay roughly 4.0 to 4.5 percent at twelve months, and UAE mortgage money costs a little under to a little over 5 percent fixed or floating. Construction instalments are precisely the part a bank will not lend against, so the marginal dirham a buyer commits early is cash or personal credit: above deposit, at or about the mortgage. 5.0 percent sits inside that band and is deliberately unheroic, because a property return assumption would produce a bigger number that is far easier to attack. The rate sets the size of the discount, not the order of it: run the whole corpus at 3 percent and the median falls to 3.23 percent, at 8 percent it rises to 8.25 percent, and the project ordering correlates 0.99998 and 0.99996 against the published rate.
Where a project publishes several plans at one headline price, the canonical one is the deepest deferral, because a buyer offered all of them at the same price takes the one worth least in present value. Plans whose name sells a cash discount are excluded from that choice, since their headline is not the headline we hold. A plan whose steps total outside 95 to 105 percent is dropped rather than rescaled: a plan summing to 60 percent is a scrape that lost a line, not a payment plan.
A figure is published only where it can be trusted. That needs an exact handover date still in the future and a plan totalling inside the band. Of 2,924 tracked off-plan projects, 1,937 qualify, 66% of the book. 661 publish no schedule we can price, 222 carry a handover date that has already passed so there is no deferral left to value, and 104 publish a schedule without a price. Those projects show nothing rather than an estimate. 113 of the 1,937 that do qualify named a post-handover tail without stating its length, so it is priced over 24 months, the shorter of the two lengths the corpus states; that understates their discount and every table that shows them labels it. A community needs 10 qualifying projects and a developer 8 before a group median is published, floors set above the project-count floors used elsewhere on this page because a single unusually deep tail moves a small median.
What the number does not account for. It credits no rent: a post-handover tail lets a buyer occupy or let the unit while still paying, so the real advantage of a tail is larger than we report, and pricing it would need a yield assumption we would then have to defend. It credits no capital growth and takes no view on where prices go. It does not price handover delay, which runs the other way: a long tail is also a long exposure to a builder slipping. And it compares plans at one headline price, so where a developer quietly discounts for early cash our figure flatters the deferred plan. It is a financing term priced in today’s money, not a forecast and not a valuation.
8. Delivery dates
Handover dates are parsed into a quarter and a year, and never invented. A date already published as a quarter, for example Q3 2027, is taken as it stands. A full calendar date is mapped to the quarter that contains it, and the exact date is kept alongside. A bare year gives a year with no quarter, so the project counts in the annual pipeline but not in the quarterly one. Anything that parses to none of these leaves the project out of the pipeline charts entirely rather than being bucketed into a guess.
9. What median, p25 and p75 mean here
All percentiles are computed by linear interpolation over the sorted list of valid records for that group. Read them like this.
- Median is the middle record: half of the priced units are cheaper per sqft, half are more expensive. It is the headline figure everywhere on this site because it is not moved by one penthouse.
- p25 and p75 are the quarter points. Half of all units sit between them, so the p25 to p75 band is the honest answer to “what does normal look like here”, and its width tells you whether a community is uniform or wildly mixed.
- Mean is shown alongside, mostly as a warning light. A mean well above the median says the distribution has a heavy top, so the average is being pulled by a small number of expensive units.
Group statistics pool the valid rows of every project in the group. A project with 400 listed units therefore contributes 400 rows and a project with 4 contributes 4, so the distribution describes available inventory rather than a per-project average. That is the right shape for a buyer asking what is on the market, and the wrong shape for asking what a typical project charges, so project-level medians are published separately in the project tables.
10. Ranking eligibility and thin pages
Ranking needs 30 or more priced units. Dubai communities are ranked against each other by median price per sqft only if the community has at least 30 valid priced records, and developers are ranked on the same threshold. A community with six units can produce a spectacular median that means nothing. Groups below the threshold still get a page and still show their figures, they simply carry no rank number and are never presented as the most expensive or cheapest anything.
Thin pages are published but not indexed. A community or developer page with fewer than 3 projects and fewer than 25 priced units is served normally, so a visitor or a link can reach it, but it is marked noindex with follow, so it is kept out of search results. It is a real page with real data, there is just not enough of it to be worth a searcher’s click. Groups thinner still, below 2 projects and below 10 units, are not given a page at all.
11. How current the data is
Three dates, and they are not the same date. The newest observation inside the records is 30 July 2026: that is what “as of” means anywhere on this site. The corpus those records sit in was last merged on 18 August 2026. The derived tables you are reading were computed on 2 September 2026. All three are derived from the data itself, none is typed by hand, and all three are printed in the footer of every page and served at /api/v1/meta.
Every figure on the site therefore describes the market as it was published up to 2026-07-30, not the market as it is this minute. Rebuilds regenerate the whole set of tables from the corpus, so a figure never drifts silently between builds.
One exception, stated rather than averaged away. 20 of the 4011 projects did not come from that corpus merge. They were picked up by a listings watcher that reads new PropertyFinder and Bayut launches continuously, and the newest of them was read on 1 September 2026. They are newer than everything around them, which is why they are not allowed to move the “as of” date: 20 records read last week say nothing about how fresh the other 3991 are. Each carries its own read date in the database, so freshness is answerable per project and not only per corpus.
12. Known limitations
- These are asking prices, not transactions. Nothing here is Dubai Land Department transaction data. An asking price is what a seller is asking, and the achieved price can differ, particularly on inventory that has been listed a long time. Use these benchmarks to see where a price sits against the rest of the market, not to state what a unit sold for.
- Starting prices can be stale. A unit-type row carries the starting price published for that layout. That figure is updated at the publisher’s discretion, and on a project that has been selling for a year it can describe a unit that was taken months ago.
- Developer-published handover dates move. The delivery pipeline reflects what developers currently say. Off-plan schedules slip, sometimes by quarters, and a rescheduled project moves in the next build without any announcement here.
- Sub-communities are rolled up. Districts, clusters and towers are folded into their parent community, which is what makes cross-community comparison possible but also averages away real internal variation. A waterfront cluster and an inland one inside the same community share a page.
- Some communities are geographically inferred. Projects assigned by nearest-neighbour proximity carry a flag, and near a community boundary that assignment can be wrong by one community.
- Coverage is uneven. A project observed on one portal only carries that portal’s granularity, so some projects contribute individual units and others contribute unit types. Projects with no published prices at all appear in the counts but contribute nothing to the price statistics.
- Off-plan only. The corpus covers off-plan and under-construction inventory. It is not a view of the ready secondary market, and the two price differently.
If you find a figure that looks wrong, tell us what it is and where you saw it at hello@offplanindex.com. Corrections go into the next build. Nothing on this site is investment advice. See also the data policy and the terms.