RE Intelligence
We took Dubai's raw public land registry and turned it into 18 focused modules - one platform where a CEO, a broker, and an analyst each see only what their job actually needs.
Design + Build - strategy, interface, data engineering, automation · Next.js 16.1 · React 19 · Supabase / PostGIS · n8n workflows · multi-model LLM
An independent intelligence layer on top of Dubai's public land registry - not another listings portal.
Dubai's DLD publishes almost everything: every sale, every off-plan unit, every Ejari rental contract. The data is open and almost unusable - millions of records in inconsistent formats, dates as text, Arabic project names, duplicate areas, garbage outliers. The raw dump is technically public and practically closed: nobody can answer a real question with it.
We took that dump and built 18 modules out of it. The point wasn't to show everything to everyone - it was the opposite. A CEO opening the platform sees strategy: forecasts, supply pipeline, pre-launch signals. A broker sees a sales toolkit: competitor intelligence, an investment calculator, area and pricing comparisons. An analyst sees the raw rails underneath - the full transactions table, projects, developers, the commercial market. Same engine, three different surfaces, each tuned to a job rather than a price tier.
One line carries the whole architecture:
Postgres owns the truth. AI owns the story. The database computes every number with a deterministic query; the model is never allowed to invent one - it only narrates what the data already proved.
One registry, eighteen surfaces
The lazy way to package a product is Basic / Pro / Enterprise - pay more, see more. It falls apart the moment you ask who the user is. A CEO and a broker don't want more or less of the same thing; they want different things. So access is modeled as jobs-to-be-done, not a ladder: CEO and Broker are a lateral switch (each has modules the other doesn't), and Analyst is the one true upgrade - a strict superset that adds the raw DLD data on top. Every role's navigation is filtered to exactly its set, so nobody wades through tools that aren't theirs.
Defaults live in a nav-config map; a singleton permissions row in the DB can override
visibility at runtime, so an admin retunes who-sees-what without a deploy - the database
is the source of truth, the code is the fallback. Personas, not tiers: "Switch" between
CEO and Broker, "Upgrade" only into Analyst.We don't flinch at the hard part
Most analytics dashboards are a thin skin over a query that runs fine on a demo dataset and dies on a real one. Our dataset is the live DLD registry - millions of transactions, millions of units, millions of rental contracts - and it grows every single day. The hard part was never the charts. It was making a median-over-a-million-filtered-rows return before the request times out, across two dozen different cuts of the same data, while new records land daily. The answer wasn't a faster query - it was refusing to run the expensive query at request time at all.
Behind the interface sits a deep engine: over a hundred custom database functions and a layer of pre-aggregated snapshots that turn "scan a million rows" into "read a small table." That's what keeps the dashboards sub-second on a dataset this size.
Expensive aggregates are precomputed into snapshot tables and read as O(rows-in-snapshot),
not O(rows-in-history) - rental medians, plot metrics, pricing filter options. Counter
metrics are computed on the full dataset; price-per-area metrics are computed only on rows
with valid area and stay nullable, so partial data can't quietly skew an average. The
canonical filters are documented once and reused everywhere, so they can't drift out of
sync across the places that depend on them. Refreshed on a cadence as new DLD data arrives.The same discipline runs through data hygiene. DLD ships impossible completion percentages, Arabic names no English UI can render, near-duplicate category labels, rental contracts dated decades into the future. None of it is "fixed" by overwriting the source - the next sync would just rewrite it back. Instead it's clamped, mapped, and filtered on read, at every point that touches the data.
The product, not the toy
A dataset is a feature. A product is the things you can do with it, every day, without thinking about the database. That's where the platform earns its keep:
- A live news feed. Real Dubai real-estate news is ingested continuously, scored and categorized - not a static list. Important stories surface as in-app notifications; AI digests roll up the day and the week.
- An AI assistant on every page. A page-aware chat sits on each dashboard. It knows what you're looking at and your active filters, and answers against a read-only, bounded query tool - it queries the real data, it doesn't make numbers up.
- A Telegram bot. Link your account once and the platform comes to you - subscribe to weekly news, new reports, and signals, or ask the bot questions directly. The bot authenticates against your real account before it answers.
- Reports that write themselves. Monthly and quarterly analytical reports are generated automatically from the data and published on a schedule - the quarterly one carries quarter-over-quarter comparison and strategic themes, the monthly one tracks the market's pulse.
- Self-grading forecasts. Price forecasts don't just predict - they're archived and measured against what actually happened, and that accuracy is shown to the user instead of hidden.
A fleet of background workflows runs the content layer on its own clock: news ingestion on
a multi-hour loop, daily and weekly digests, weekly anomaly detection, monthly and quarterly
report generation, per-competitor-group briefs, and the Telegram bot. Model routing is
deliberate - fast models classify, strong models write, embeddings dedupe - because using an
expensive model to label an edit is as wrong as using a cheap one to write a strategy report.A signal nobody else is watching
The differentiated bet is the Pre-Launch Signal - spotting developers quietly accumulating land before a project is ever announced. A cluster of mid-size land purchases in a community with no off-plan supply yet is a launch being born. By the time the towers hit a brochure, the signal is months old. The platform classifies every community by the interplay of land-buying activity and existing supply, and flags the pre-launch state as its own widget that cross-links from the supply pipeline.
Each community is bucketed over a rolling window into a handful of lifecycle stages, driven
by the relationship between developer land-buying velocity and the off-plan / resale supply
already in the ground. The interesting state is high land accumulation with supply still near
zero - the window before the crowd arrives. Thresholds were tuned empirically against the
city's most active communities. (Exact rules withheld - that's the proprietary part.)Honesty is the invariant
What makes it a platform a professional trusts is what it refuses to do. It never presents an AI number as fact without the deterministic query behind it. It shows its forecast accuracy instead of hiding misses. It clamps and labels dirty source data rather than silently "correcting" it. It renders heatmaps only for the areas it actually has geometry for, with the full picture always available in the tables underneath.
- AI narrates numbers; it never invents them.
- Forecasts are graded against reality, in public.
- Dirty registry data is clamped on read, never overwritten at the source.
- Incomplete coverage is shown as incomplete, not faked.
- The human is the only one who publishes.
Result
We turned the public DLD dump - the thing everyone can download and nobody can use - into a working intelligence platform: 18 role-tuned modules over the full Dubai registry, refreshed daily, served sub-second from a deterministic engine, with an AI layer that only ever speaks for numbers the data already earned. Independent, comprehensive, and honest about its own limits - the analytics layer the public registry never shipped.
Next.js 16.1 (App Router, Server Components) + React 19.2 + TypeScript 5.7 (strict) ·
Supabase (Postgres + PostGIS for area polygons, Auth via JWT/middleware) · data served
through 100+ parameterized RPC functions + pre-aggregated snapshot caches (the engine,
not the ORM) · Recharts + MapLibre GL choropleth heatmaps via OpenFreeMap · SWR data
fetching · shadcn/ui + Radix + Tailwind (light/dark) · n8n workflows for news, signals,
digests, reports, competitor briefs and a Telegram bot · multi-model LLM via OpenRouter +
Perplexity (fast models classify, strong models write) · nodemailer SMTP · on Vercel.