DEV Community: Get Anything

GCC Tech Salaries in 2026: How to Track Vision 2030 Hiring & Pay with Live Data

Get Anything — Tue, 28 Jul 2026 04:28:37 +0000

The Gulf is in the middle of the biggest hiring wave in its history. The six GCC states are projected to hire around 2.5 million skilled professionals over three years, Saudi Arabia is targeting 50,000 new tech jobs under Vision 2030, and senior-developer pay in the UAE and Saudi Arabia is reportedly inflating 15–25% a year. Salaries overall are forecast up ~4.6% in Saudi and ~4.1% in the UAE for 2026.

If you're recruiting, job-hunting, or building a jobs product in this market, generic salary surveys are already stale by the time they publish. Here's how to track live GCC salary and hiring data yourself.

The problem: most Gulf job boards hide salary

Bayt, GulfTalent and NaukriGulf rarely publish pay. The two sources that do — Indeed and Glassdoor — sit behind Cloudflare and heavy anti-bot protection, so a normal scraper just hits a "Security Check" page.

The fix: pull salary-tagged jobs across the Gulf

Two ready-made tools get past the anti-bot walls (using a hardened, fingerprint-spoofing browser) and return structured jobs with salary:

Indeed Scraper — GCC Jobs, Salaries & Employers — 70–80% of GCC listings carry a salary range, plus employment type, remote flag and company rating.
Glassdoor Scraper — GCC Jobs & Salary Data — employer-provided salary ranges and company data.

Give each a keyword (e.g. "software engineer", "data scientist", "AI engineer") and one or more countries (UAE, Saudi Arabia, Qatar, Kuwait, Bahrain, Oman).

Example (Indeed) output

{
  "title": "Senior Software Engineer",
  "company": "…",
  "city": "Riyadh",
  "country": "Saudi Arabia",
  "employmentType": "full-time",
  "salaryText": "SAR 25,000 - SAR 35,000 a month",
  "salaryMin": 25000,
  "salaryCurrency": "SAR"
}

Track the trends that matter in 2026

Vision 2030 tech demand — software, full-stack, data science, AI/ML roles in Riyadh, NEOM, Dubai
Tech salary inflation — benchmark senior-dev pay month over month
Saudization — which roles are shifting to Saudi-national-only and how pay moves with it
Sector shifts — tourism, construction, healthcare, education (5,000+ teaching roles a quarter)

Want coverage first, salary second?

Start with the free flagship: GCC Jobs Search — searches Bayt, GulfTalent, NaukriGulf, Foundit and Tanqeeb together with filters for field, experience, city, salary and company, then layer Indeed/Glassdoor for salary depth.

Ask it in plain English

All three plug into ChatGPT/Claude via the Apify MCP server:

"What do senior data engineers earn in Riyadh right now?"

Tools: Indeed GCC · Glassdoor GCC · GCC Jobs Search (free). By Get Anything.

Build a Dubai Real Estate AI Agent with MCP (No Code) — Asking Price vs Sold Price

Get Anything — Tue, 28 Jul 2026 04:27:43 +0000

AI agents are only as good as the tools you give them. Ask ChatGPT or Claude "what's a fair price for a 1-bed in JVC?" and you'll get a vague, out-of-date guess — because the model has no live data. The fix in 2026 is MCP (Model Context Protocol): you connect real data tools to your assistant, and it answers with actual numbers.

Here's how to give an AI assistant two Dubai property superpowers — live asking prices and real sold prices — with no code.

The two tools your agent needs

The gap every property decision hinges on is asking price vs sold price:

Bayut Property Scraper — live listings (what sellers ask): price, beds, baths, area, agent, for sale or rent, across Dubai and the UAE.
Dubai DLD Transactions Scraper — Dubai Land Department registered transactions (what buyers paid): price per sqm, first-sale vs resale, by community — free, no API key.

Both are Apify Actors, and both are MCP-ready.

Connect them in ~2 minutes

Open the Apify MCP server.
Add the two Actors above as tools.
Point your MCP client (Claude Desktop, ChatGPT, Cursor, or any MCP-compatible app) at the server.

That's it — your assistant can now call them.

What you can now ask

"What's the average sold price per sqm for flats in Dubai Marina this month, first-sale vs resale?"

"Find 2-bed apartments for sale in JVC under AED 1.2M, then tell me how that compares to what 2-beds actually sold for there."

"Which communities had the most transactions last month, and what's the off-plan vs resale split?"

The agent calls Bayut for the listings, DLD for the registered prices, and reconciles them — the kind of answer that used to need an analyst and a spreadsheet.

Why this matters in 2026

Dubai just posted its biggest half-year on record (~AED 291.7bn, ~71% off-plan), and prices are up ~9%. In a market moving this fast, static reports are stale on arrival. An MCP agent wired to live listings + registered transactions gives you an always-current answer to "is this priced right?"

Beyond real estate

The same pattern works for hiring: connect the Indeed and Glassdoor GCC scrapers and ask your assistant "what do senior developers earn in Riyadh right now?"

Tools: Bayut · Dubai DLD Transactions. More AI-ready Gulf data tools by Get Anything.

Dubai Off-Plan vs Resale in 2026: What the DLD Transaction Data Actually Shows

Get Anything — Tue, 28 Jul 2026 04:27:42 +0000

Dubai's property market just had its biggest six months on record — 87,800 transactions worth around AED 291.7 billion in H1 2026, with average prices up ~9% and off-plan making up roughly 71% of all volume. Every headline is about off-plan. But if you're actually deploying capital, the question isn't "is off-plan hot?" — it's "first-sale or resale, in which community, at what price per sqm, right now?"

The only data that answers that is registered transaction data from the Dubai Land Department (DLD) — not the asking prices on the portals. Here's how to pull it and read the off-plan vs resale story yourself.

Why "off-plan vs resale" is the metric that matters

The DLD tags every sale with a sale sequence: first sale (off-plan / primary, straight from the developer) or resale (secondary market). That single flag tells you:

Where the primary pipeline is concentrated — first-sale volume clusters in emerging communities with new launches (Dubai South, JVC, Dubai Islands, Dubai Creek Harbour).
The premium/discount between primary and secondary — first-sale price per sqm vs resale price per sqm in the same community, the same month.
Momentum — rising resale volume in an off-plan-heavy area signals an exit market forming.

How to get it (free, no API key)

The DLD publishes this on its public transactions page. Instead of wrangling it by hand, the Dubai DLD Transactions Scraper turns it into clean JSON for any date range — one record per community × sub-type × sale sequence, with pricePerSqmAed, avgTransactionValueAed, transactionCount and totalValueAed, in English and Arabic.

Example: reading the split in JVC

For Jumeirah Village Circle — one of the highest-volume communities in 2026 — the data separates:

{ "community": "JUMEIRAH VILLAGE CIRCLE", "propertySubType": "Flat",
  "saleSequence": "First",  "transactionCount": 118, "pricePerSqmAed": 16218 }
{ "community": "JUMEIRAH VILLAGE CIRCLE", "propertySubType": "Flat",
  "saleSequence": "Second", "transactionCount": 110, "pricePerSqmAed": 12106 }

First-sale (off-plan) clears higher per sqm than resale in the same community — the "new-build premium" you can now quantify per area, per month.

What to build with it

Off-plan heat maps — first-sale volume by community over time
Primary vs secondary price gap trackers
Absorption / exit signals — when resale volume rises in an off-plan area
Valuation comparables grounded in registered prices, not listings

Pair it with live listings

To see asking vs sold in the same community, add the Bayut Property Scraper (live listings: price, beds, area, agent). Asking price from Bayut, sold price from DLD — the full gap in one view.

Ask it in plain English

Both tools plug into ChatGPT/Claude via the Apify MCP server:

"Compare off-plan vs resale price per sqm in Business Bay this quarter."

Tool: Dubai DLD Transactions Scraper · more Gulf data tools by Get Anything.

Scraping bilingual data: the Arabic/English traps that quietly corrupt your dataset

Get Anything — Mon, 27 Jul 2026 11:29:17 +0000

Most scraping advice assumes one language. Build for a bilingual market and you meet a category of bug that never throws an exception: the request succeeds, the HTML parses, and every field you wanted comes back empty.

Here is what I learned building job datasets that have to work in both Arabic and English.

The bug that returns null instead of failing

I was fetching job detail pages and extracting the stated seniority and employment type. The parser looked for the labels the page uses, matched them, and pulled the adjacent value. It worked in testing.

In production, seniorityStated and employmentType came back null for every record. No error. Status 200. Valid HTML.

The links I was following pointed at a regional subdomain. That subdomain served the Arabic version of the page. My selectors were matching on the English labels — "Seniority level", "Employment type" — and the page said المستوى الوظيفي and نوع التوظيف. Nothing matched. Nothing raised. The fields were simply absent.

The fix was one line: normalize the host before fetching.

import re

# Regional hosts serve localized pages whose labels don't match
# English selectors. Normalize to the canonical host.
url = re.sub(r"https://[a-z]{2}\.example\.com/", "https://www.example.com/", url)

The lesson generalizes: a scraper that finds nothing and a scraper that finds the wrong language look identical from the outside. If a field is null across every single record, suspect locale before you suspect your selector.

Assert on what you expect to find

The defence is cheap. After a parse, check that the fields you rely on actually populated:

critical = ("seniority", "employmentType")
missing = [f for f in critical if not any(r.get(f) for r in records)]
if missing:
    raise RuntimeError(f"No record has {missing} — wrong locale or stale selector?")

A scraper that crashes loudly on an empty column is worth ten that return tidy nulls.

Numerals are not the digits your regex expects

Arabic pages frequently use Eastern Arabic numerals. ٢٠٠ is two hundred.

Python is more helpful here than people assume, which is exactly why this bites. int("٢٠٠") returns 200. "٢٠٠".isdigit() is True. re.findall(r"\d+", ...) finds them, because \d is Unicode-aware by default.

The thing that silently fails is the character class almost everyone actually writes:

import re

text = "أكثر من ٢٠٠ متقدم"          # "more than 200 applicants"

re.findall(r"[0-9]+", text)          # []          <- silently empty
re.findall(r"\d+", text, re.ASCII)   # []          <- same trap
re.findall(r"\d+", text)             # ['٢٠٠']     <- works
int("٢٠٠")                           # 200         <- works

So a scraper that extracts applicant counts with [0-9]+ doesn't crash on an Arabic page. It reports that the page contains no numbers, forever, and you conclude the field is missing rather than that your regex is ASCII-only.

If you want ASCII digits in your output regardless of the source, translate rather than strip:

ARABIC_DIGITS = str.maketrans("٠١٢٣٤٥٦٧٨٩", "0123456789")

def to_int(text):
    return int(re.sub(r"\D", "", text.translate(ARABIC_DIGITS)))

I nearly published the claim that int() raises on Arabic numerals. It doesn't. I only found out because I ran the snippet before shipping the article, which is the entire moral of this post.

Don't let a substring match decide a language

Keyword matching across languages goes wrong in ways that are hard to see. Two real examples from classifying job titles:

Matching the seniority abbreviation coo as a substring also matches "Coordinator". A programme coordinator became a chief operating officer.
Matching partner as a substring promoted "Partner Onboarding Specialist" to firm partner.

Word boundaries fix both. But the general point is sharper in a bilingual dataset, where titles mix scripts, transliterations and English loanwords in the same string. re.search(r"\bcoo\b", title), never "coo" in title.

Print the rows behind the number

I was about to publish a statistic saying 18% of roles in a market were executive-level. It felt too high, so I printed the titles in that bucket. Half of them were coordinators and onboarding specialists. The real figure was 16%, and the composition was completely different.

Every heuristic you write will be wrong in a way that flatters your numbers. Print the rows.

Machine translation is for labels, not for meaning

If you add Arabic labels to an English dataset, keep the original. Store title and titleArabic side by side; never overwrite. Translation is lossy, brand names transliterate inconsistently, and someone downstream will want to match on the original string.

For job titles specifically, a translated label is a display convenience. Every join, dedupe and filter should still run on the source-language field.

Encoding, briefly

Set your encoding explicitly at every boundary: reading files, writing files, and printing. On Windows the default console encoding will happily raise UnicodeEncodeError on a perfectly good Arabic string, which sends you hunting for a scraping bug that doesn't exist.

sys.stdout.reconfigure(encoding="utf-8")
pathlib.Path(p).read_text(encoding="utf-8")

Also: a UTF-8 byte order mark at the start of a JSON file will make some parsers reject it outright. If a tool insists your valid JSON is invalid, check for a BOM before you check your syntax.

Where this came from

I maintain scrapers for regional job boards that output company and role labels in both Arabic and English. All of the above is scar tissue from building them.

They're on my Apify page

How to build a hiring intent score that doesn't lie to you

Get Anything — Mon, 27 Jul 2026 11:29:09 +0000

You have a list of companies and their open roles. You want one number per company: how hard is this company hiring, right now?

That number is easy to compute and easy to get wrong in ways that look plausible. Here's a design that survives contact with real data, and the specific mistakes that inflate every naive version.

The three inputs

Volume. How many roles are open. The most obvious input and the least interesting on its own, because it scales with company size. Ten open roles at a fifty-person startup means something very different from ten at a ten-thousand-person bank.

Seniority mix. What kind of roles. Weight senior and executive postings higher. A company creating a director-level position it never had is starting something; a company posting three interns is running a graduate scheme. Seniority is the closest proxy for "new initiative" that a job title gives you.

Momentum. How the count changed since last time. This is the input everyone skips, because it requires storing state across runs, and it's the one that carries the most information. A company that went from two roles to eight is in a different state from one that has had eight open for a year.

A workable formula

SENIORITY_WEIGHTS = {
    "Internship": 0.2,
    "Entry level": 0.4,
    "Mid level": 0.6,
    "Mid-Senior level": 0.8,
    "Director": 1.0,
    "Executive": 1.0,
}

def hiring_intent(job_count, seniority_mix, delta):
    # Volume: log-ish, so 40 roles doesn't drown out everything else
    volume = min(job_count / 10, 1.0)

    # Seniority: weighted average of the mix
    total = sum(seniority_mix.values()) or 1
    seniority = sum(SENIORITY_WEIGHTS.get(k, 0.5) * v
                    for k, v in seniority_mix.items()) / total

    # Momentum: unknown on the first run, and that's not the same as zero
    momentum = 0.5 if delta is None else min(max(delta, 0) / 5, 1.0)

    return round(100 * (0.5 * volume + 0.3 * seniority + 0.2 * momentum), 1)

Cap volume rather than letting it run linearly, or the largest company in your list wins every time and the score becomes a headcount proxy.

Note delta is None. On the first run you have no previous state. A first run is not a company with zero momentum — it's a company whose momentum you don't know. Scoring those identically means every company looks stagnant on day one, and your first Monday's call list is garbage. Give unknown momentum a neutral value and label the run as a baseline.

The trap that will inflate your score

Seniority weighting is where this breaks, because it depends on a classifier that reads job titles, and job titles are adversarial.

Three bugs I shipped, all of which made companies look more senior than they were:

"coo" in title.lower() matches "Coordinator". Every programme coordinator became a chief operating officer.

"partner" in title.lower() matches "Partner Onboarding Specialist" and "Partnerships Lead". Support staff became firm partners.

"Assistant Vice President" is not an executive. In banking and real estate it's an upper-mid individual contributor title. A single company's AVP postings pushed my executive count up by seven.

The first two are fixed with word boundaries:

re.search(r"\b(ceo|cfo|cto|cmo|coo)\b", title)   # not `"coo" in title`

The third is fixed by ordering your rules so the specific case is caught before the general one:

if "assistant vice president" in t or "avp" in t:
    return "Mid-Senior level"          # must come first
if "vice president" in t or "chief" in t:
    return "Executive"

Together these took my "executive-level roles" figure from 18% of a market down to 16%, and changed which companies ranked highest. I nearly published the wrong number.

Validate by reading, not by eyeballing percentages

The check that catches all three of the above takes one minute:

from collections import Counter
for bucket, count in Counter(r["seniority"] for r in records).most_common():
    print(f"\n=== {bucket}: {count}")
    for r in [x for x in records if x["seniority"] == bucket][:10]:
        print("   ", r["title"])

Print the titles inside each bucket. Every classification bug I have written was invisible as a percentage and obvious as a list. If "Executive" is 18% of your dataset, look at who's in it before you tell anyone.

Make the score legible

A score of 73 is useless on its own. Ship the components alongside it:

{
  "company": "Example Co",
  "hiringIntentScore": 73.0,
  "openRoles": 8,
  "trendDelta": 3,
  "seniorityMix": {"Mid-Senior level": 5, "Director": 2, "Entry level": 1},
  "sampleTitles": ["Director of Engineering", "Senior Data Engineer"]
}

Anyone using the score to decide where to spend their week needs to see why a company ranks where it does. A high score driven by twenty interns is not the same as one driven by three director hires, and the person making the call should be able to tell those apart at a glance.

Weekly, or it means nothing

Momentum requires a previous run. Score once and you have a snapshot with the most valuable input missing. Run it on a fixed weekly schedule, store each run's per-company counts, and compare consecutive runs.

One caution: never persist state from a run where a source failed. A partial fetch writes a truncated baseline, and next week every missing role looks like it closed. Suppress the closure signal on any incomplete run.

Ready-made

I maintain a tracker that does exactly this: aggregates open roles per company, infers seniority and function from titles, compares against the previous scheduled run, and returns a 0–100 hiring intent score with all its components attached.

It's on my Apify page

The same job is posted on three boards. Here's how to deduplicate job listings properly.

Get Anything — Mon, 27 Jul 2026 11:29:00 +0000

Search any regional job board for a role and you will meet the same position three times, under three slightly different titles, from three sources.

The company entered it once. The boards each reformatted it. If you are aggregating listings, you now have a deduplication problem, and it's harder than it looks: the naive fixes either merge two genuinely different jobs or fail to merge two copies of the same one.

Why exact matching fails

The same posting, as three boards render it:

E-Commerce Executive              | Example Trading Co | Dubai, United Arab Emirates
E-commerce Executive              | Example Trading Co | Dubai - UAE
E-Commerce Executive (FMCG)       | EXAMPLE TRADING CO | Dubai

Nothing matches exactly. Case differs, the location string differs, one board appended a category, one uppercased the company. An exact-match key finds zero duplicates here and you publish the same job three times.

Why fuzzy matching also fails

The obvious next step is fuzzy string similarity on the title. Set a threshold, merge anything above it. This works until it meets real data:

Senior Accountant     vs  Senior Accountant     — same job? Maybe. Two different teams?
Sales Manager (Dubai) vs  Sales Manager (Abu Dhabi) — 92% similar, definitely different jobs
Data Analyst I        vs  Data Analyst II       — 95% similar, different seniority, different pay

Titles are short. Short strings are similar to each other by accident. Any threshold loose enough to catch "E-Commerce Executive" and "E-commerce Executive (FMCG)" is also loose enough to merge two roles in different cities.

What actually works: a normalized composite key

Match on the pieces that identify a job, normalize each aggressively, and require all of them:

import re

def normalize(text):
    """Lowercase, strip everything that isn't alphanumeric."""
    return re.sub(r"[^a-z0-9]+", "", (text or "").lower())

def job_key(job):
    return "|".join([
        normalize(job["title"]),
        normalize(job.get("company") or job.get("location") or ""),
    ])

E-Commerce Executive and E-commerce Executive both collapse to ecommerceexecutive. Company does the same. Sales Manager (Dubai) and Sales Manager (Abu Dhabi) stay apart because the parenthetical survives normalization.

Falling back to location when the company is missing matters more than it sounds: some boards omit the employer for confidential postings, and keying on title alone would merge every "Sales Manager" in the country into one row.

Merge, don't discard

When two records collapse to the same key, don't pick one and throw away the other. Different boards carry different fields. Take the union:

def merge(records):
    merged = {}
    for job in records:
        key = job_key(job)
        if key not in merged:
            rec = dict(job)
            rec["sources"] = [job["source"]]
            rec["allLinks"] = {job["source"]: job["url"]}
            merged[key] = rec
            continue

        rec = merged[key]
        rec["sources"] = sorted(set(rec["sources"] + [job["source"]]))
        rec["allLinks"][job["source"]] = job["url"]
        # Fill gaps from whichever source has the field
        for field in ("company", "location", "postedDate", "salaryText", "description"):
            if not rec.get(field) and job.get(field):
                rec[field] = job[field]
    return list(merged.values())

One board gives you a salary range, another an accurate posted date, a third the full description. The merged record is better than any single source, and sources tells the reader where the job appears — genuinely useful, because applying through the board with the fewest applicants is a real strategy.

Keep the merge rate honest

The number worth watching is how many records collapsed. Publish it:

58 raw postings → 51 records (7 merged)

If that ratio ever hits something implausible — 200 postings collapsing to 12 — your key is too loose and you are merging distinct jobs. If it never merges anything, your normalization isn't doing its job. In my own runs a cross-board merge rate around 10 to 15 percent looks right for a single keyword; much higher and I go read the rows.

Which is the general lesson. Print the rows behind any aggregate before you trust it. Every deduplication bug I've shipped looked perfectly reasonable as a percentage and obviously wrong as a list of titles.

Don't dedupe before you filter

Order matters. If you cap results per source before merging, you throw away the copy that had the salary field. If you filter by location before normalizing, you drop Dubai - UAE while keeping Dubai. Fetch fully, normalize, merge, then filter and cap.

The ready-made version

I maintain a scraper that searches the three largest regional job boards in one run and merges duplicates exactly this way, returning one record per role with every source it appears on. Pricing is per merged record, so cross-posted jobs are billed once rather than three times.

It's on my Apify page

Track new job postings the week they appear, with a scheduled scraper and a diff

Get Anything — Mon, 27 Jul 2026 11:28:52 +0000

One scrape of a careers page tells you what's open. Two scrapes, a week apart, tell you what changed — and the change is where the value is.

A role that appeared three days ago has a handful of applicants. The same role a month later has hundreds. If you are job hunting, that gap is most of the advantage you can actually control. If you are selling to companies, a role that just opened is a signal that a team is growing and has budget.

Here's how to build it.

The idea

Run the same scrape on a schedule. Store each run's job IDs. Compare consecutive runs:

IDs in the new run but not the old one → newly posted
IDs in the old run but not the new one → closed or filled
Count per company over time → hiring momentum

That's the whole trick. The engineering is small; the discipline is in keeping a stable identifier.

Use a stable ID, not the title

The most common mistake is diffing on job title. Titles get edited. "Senior Engineer" becomes "Senior Software Engineer" and suddenly your diff reports one role closed and one opened, on the same day, for the same job.

Every applicant tracking system returns a stable ID per posting. Use it, and keep the URL as a tiebreaker:

def job_key(job):
    return job.get("jobId") or job["url"]

Titles and locations belong in the output, never in the key.

The diff

import json
from pathlib import Path

STATE = Path("last_run.json")

def diff(current_jobs):
    current = {job_key(j): j for j in current_jobs}
    previous = json.loads(STATE.read_text()) if STATE.exists() else {}

    opened = [current[k] for k in current.keys() - previous.keys()]
    closed = [previous[k] for k in previous.keys() - current.keys()]

    STATE.write_text(json.dumps(current))
    return opened, closed

On the very first run, previous is empty and everything looks new. Handle that explicitly rather than emailing yourself 500 "new" jobs:

first_run = not STATE.exists()
opened, closed = diff(jobs)
if first_run:
    print(f"Baseline stored: {len(opened)} jobs. No alerts on the first run.")
else:
    print(f"{len(opened)} new, {len(closed)} closed")

Two failure modes that will lie to you

A failed fetch looks like mass closure. If one company's board times out and you write the partial result as your new state, next week's diff reports every one of that company's jobs as "closed," then as "newly opened" the week after. Never persist state from a run where any source errored:

if errors:
    print("Skipping state update — incomplete run")
    return opened, []          # report opens, suppress the false closures

This one bit me. A source silently returned an empty list, and the diff cheerfully announced that a company had closed every role it had.

Pagination that stops early looks the same. If your scraper quietly collects 40 of 2,000 jobs because a paginated endpoint throttled you, the diff will report 1,960 closures. Assert that the count you fetched matches the total the API reports, and fail loudly when it doesn't.

Reading momentum

Once you have a few weeks of runs, the count per company is more interesting than any single posting:

from collections import Counter

def momentum(runs):                       # runs: list of {company: count}
    latest, prior = runs[-1], runs[-2]
    return {c: latest.get(c, 0) - prior.get(c, 0) for c in set(latest) | set(prior)}

A company that added six roles this week and four the week before is expanding. One that closed eight without opening any either finished a hiring round or stopped hiring. Both are worth knowing, and neither shows up in a single snapshot.

Weight by seniority if you want a sharper signal. A new VP posting says something different from a new intern posting: senior hires usually mean a new function is being built, not a backfill.

Scheduling it

Any scheduler works: cron, GitHub Actions, a hosted platform. Two rules regardless:

Run at the same time each week. Diffs across uneven intervals aren't comparable.
Keep the raw output of every run, not just the diff. When a number looks wrong — and eventually one will — you need the underlying rows to check it against. Every aggregate I've published that surprised me turned out to be a bug, and the raw data is what proved it.

Doing it without writing any of this

My ATS scraper reads five applicant tracking systems and returns a normalized record per job, with a stable ID. Point it at a list of companies, schedule it weekly, and diff the datasets. It's free to run.

The hiring-signal tracker takes it further: it does the diff for you, aggregates per company, and scores hiring momentum by role volume, seniority and week-over-week change.

Both are on my Apify page

What this is not

A diff tells you a role appeared. It doesn't tell you the team is good, the salary is fair, or the posting isn't a pipeline-filling exercise that's been reposted quarterly for two years. Being early is a real edge, and it is the only part of this a scraper can give you.

How to find Dubai jobs before they appear on job boards

Get Anything — Mon, 27 Jul 2026 11:28:41 +0000

There is a gap between the moment a recruiter publishes a job and the moment you see it on LinkedIn. The role goes live on the company's own career page first. Everything else, LinkedIn, Bayt, Indeed, GulfTalent, is downstream of that.

By the time a Dubai role trends on LinkedIn, it can already have 200 applicants. I scraped one recently that said exactly that: "Over 200 applicants," on a role posted two days earlier.

You can read the source instead. It's public, and it's free.

Why the career page is the source

Companies don't type jobs into LinkedIn. They enter them once into an applicant tracking system, Greenhouse, Lever, Ashby, Workday, and that system pushes copies outward to job boards on its own schedule. The company's own careers page reads from that database directly.

So the career page is always first, always complete, and never reordered by an algorithm that thinks you'd like a role in a different country.

The catch: most Gulf giants aren't readable

I checked 42 of the region's most sought-after employers. Only 7 publish their jobs through a system with an open, readable feed.

Emirates Group, ADNOC, Emaar, Majid Al Futtaim, Qatar Airways, DP World, Emirates NBD, Aramco, talabat and noon all run on older enterprise systems (Taleo, Oracle, Phenom) with no public feed. For those, you genuinely do have to check their careers page by hand, or use an aggregator.

But the seven that are readable happen to be among the most interesting employers in the region.

The companies you can watch in real time

Company	Hiring in	Currently open
Aldar Properties	Abu Dhabi	48 roles
Tamara	Dubai, Riyadh	31 roles
Deliveroo	Dubai	26 roles
Masdar	Abu Dhabi	23 roles
Careem	Dubai	11 roles
Fresha	Riyadh	9 roles
Lean Technologies	Riyadh	4 roles

Those numbers were live on 10 July 2026. Run the tool below and you'll get today's.

Two things the data will tell you that surprise most job seekers

Abu Dhabi has more open roles than Dubai. In this dataset, 70 versus 50. Aldar and Masdar are hiring heavily, and most job seekers filter on "Dubai" out of habit and never see them.

Only 16% of roles are entry level or internships. Forty-five percent are mid-senior. If you're early in your career, the Gulf market at these companies is tighter than the headlines suggest, and the honest advice is to target the mid-level roles that ask for three years rather than the graduate schemes that barely exist.

How to watch them, free

I built a free tool that reads all seven career pages at once and hands you a clean spreadsheet. It needs no account with any of these companies and no login.

Run it with this input:

{
  "companies": [
    "lever:aldar",
    "greenhouse:careem",
    "greenhouse:tamara",
    "smartrecruiters:masdar",
    "ashby:deliveroo",
    "lever:fresha",
    "ashby:leantech"
  ],
  "locationFilter": "Dubai"
}

Run it free here

Change "Dubai" to "Abu Dhabi", "Riyadh", or delete the line to see everything. Export to CSV or Excel with one click.

Set it to run every Monday

The real advantage isn't one run, it's the diff. Schedule it weekly and compare: the roles that appear this week are the ones nobody has applied to yet. That's the window where your application is read by a human rather than counted.

If you need the big employers too

For the Gulf companies that don't expose a feed, Emirates, ADNOC, Emaar, Majid Al Futtaim and the rest, I built a second tool that searches Bayt, GulfTalent and NaukriGulf together and merges duplicate postings, so you see each role once with every place it appears.

GCC Jobs Aggregator

A realistic note

None of this replaces a referral. What it does is buy you time: applying on day one instead of day ten, and seeing roles in Abu Dhabi that your Dubai filter was hiding. In a market where mid-senior roles get hundreds of applicants, being early is most of the advantage you can actually control.

Job postings are the most underrated buying signal in B2B sales

Get Anything — Mon, 27 Jul 2026 11:28:20 +0000

Sales teams pay a great deal for intent data: who visited your pricing page, who researched your category, who downloaded a competitor's whitepaper. It's inferred, probabilistic, and expensive.

Meanwhile, companies publish an explicit, dated, public statement of what they intend to do next. It's called a job posting, and almost nobody in sales is reading it systematically.

What a job posting actually tells you

A company posting a role has already done the hard part internally. Someone wrote a business case. Someone approved headcount. Finance allocated budget. That process takes weeks and it does not happen for a team that is standing still.

So the posting tells you, with far more confidence than a page visit:

There is budget. Headcount is the hardest spend to approve.
There is a gap. They are hiring for a capability they don't have enough of.
There is a timeline. Roles get posted when the work is already waiting.
There is an owner. The hiring manager is your buyer, or reports to them.

Read the role and you learn the shape of the problem. A company hiring its first data engineer has a data problem it has decided to stop tolerating. One hiring three sales development reps is about to need sales tooling, enablement content and probably a CRM cleanup. One hiring a compliance officer just entered a regulated market.

Volume and seniority carry the signal

One posting is noise. The pattern is signal.

Volume tells you the scale of the initiative. A company with one open engineering role is backfilling. One with eleven is building something.

Seniority tells you whether it's new or routine. Senior and executive roles usually mean a new function is being created, not a seat being filled. When a company posts a VP of a function it didn't previously have, it has decided that function matters — and the person hired into it will spend budget in their first ninety days.

Momentum tells you the direction. Roles added since last month matter more than a stale list of everything open. A company that added six roles this week is in a different state from one that has had the same six open since March.

Combine them and you can rank a target list by how likely each account is to be actively spending. That's the whole idea behind a hiring-intent score: weight role volume, weight the seniority mix, weight the change since the last check, and sort.

The timing advantage is real

There is a window between a role appearing on a company's own careers page and that role becoming widely visible. During that window, the initiative is being planned rather than executed. That's when a vendor conversation is welcome, and it's the opposite of arriving after the tool has been chosen.

Checking weekly and diffing against last week's list turns this into a routine rather than a research project. New roles this week are your call list.

Three ways to get this wrong

Treating every posting as new. Companies repost roles they cannot fill. A "new" listing that has been reposted quarterly for two years is not a signal of momentum; it's a signal of a hard-to-fill role. Diff against your own previous scrapes rather than trusting a posted date.

Confusing titles with seniority. In banking and real estate, "Assistant Vice President" is an upper-mid individual contributor, not an executive. I built a classifier that got this wrong and my "executive hiring" numbers were inflated by a third until I read the underlying titles. If you rank accounts by executive hiring, be sure you know what an executive is in that industry.

Pitching the recruiter. The person named on the posting is in talent acquisition. They are not your buyer, they are measured on time-to-fill, and a sales email is friction in their week. Use the posting as evidence about the team, then find the team's leader.

The honest limitations

A job posting tells you a company is spending. It does not tell you they are dissatisfied with an incumbent, that your product fits, or that the timing is right for a purchase rather than a hire. Companies also post roles they never fill, post to benchmark salaries, and post to look like they're growing.

Treat it as the strongest freely available signal of budget and intent, not as a qualified lead. It gets you a well-timed, well-informed first sentence. The rest of selling is unchanged.

Doing it without a research team

I built a tracker that aggregates open roles per company, scores hiring intent from volume, seniority mix and week-over-week change, and flags which companies added roles since the last run. It outputs one row per company with the roles attached, so you can read the shape of what they're building.

It's on my Apify page

Run it on a schedule against your target accounts and read the diff on Monday morning. That is the entire workflow.

I tested 42 large employers to see which ones you can actually scrape. Only 7 worked.

Get Anything — Mon, 27 Jul 2026 11:27:34 +0000

Before you write a scraper for a company's careers page, ask a cheaper question: is the data even reachable?

I checked 42 of the most sought-after employers in one region. Seven were reachable. The other thirty-five were not, and no amount of clever parsing would have changed that.

Here is how the split works, and how to test any company in a single request.

Two kinds of applicant tracking system

Companies don't type jobs into job boards. They enter each role once into an applicant tracking system, and that system pushes copies outward.

Modern ATS platforms publish an open job board API. Greenhouse, Lever, Ashby and SmartRecruiters all serve their job data as JSON to anyone who asks. No key, no login, no browser. They do this deliberately: companies want their roles discovered and syndicated.

Enterprise ATS platforms do not. Taleo, Oracle Cloud Recruiting, Phenom and iCIMS render jobs through session-bound, JavaScript-heavy portals with no public feed. Some of them will happily block you for trying.

That distinction predicts almost everything about whether scraping a given company is going to be pleasant or miserable.

The result: 7 of 42

The 35 unreachable companies weren't small. They included the region's largest airline, its national oil company, its biggest property developers, its major banks, and its best-known retail groups. Household names, all of them running enterprise portals with no public feed.

The seven reachable ones had something in common. They were the newer, faster-moving companies: a fintech, a delivery platform, a real-estate developer that recently modernised, a clean-energy firm, a booking platform. Companies that adopted their ATS in the last several years, when Greenhouse and Lever were the default choice.

This is not a knock on the larger companies. Enterprise HR systems solve problems that a startup doesn't have. It just means their job data isn't available at the source, which is why aggregators show incomplete or stale listings for exactly the employers people search for most.

Check any company in one request

Fetch the careers page and look for the ATS signature in the HTML:

import re
import requests

SIGNATURES = [
    ("greenhouse",      r"boards\.greenhouse\.io/([\w-]+)"),
    ("lever",           r"jobs\.lever\.co/([\w-]+)"),
    ("ashby",           r"jobs\.ashbyhq\.com/([\w.-]+)"),
    ("smartrecruiters", r"careers\.smartrecruiters\.com/([\w-]+)"),
    ("workday",         r"([\w-]+)\.(wd\d+)\.myworkdayjobs\.com/([\w-]+)"),
    # Present but not scrapeable — worth naming so you stop early:
    ("taleo",           r"taleo\.net"),
    ("oracle",          r"oraclecloud\.com|/hcmUI/CandidateExperience"),
    ("phenom",          r"phenompeople"),
    ("icims",           r"icims\.com"),
]

def detect(careers_url):
    html = requests.get(careers_url, timeout=20).text
    for ats, pattern in SIGNATURES:
        m = re.search(pattern, html)
        if m:
            return ats, m.groups()
    return None, None

If it comes back taleo, oracle, phenom or icims, stop. You are looking at days of brittle browser automation for data that will break next quarter. Spend the time on the companies you can read properly, and get the rest from job boards.

Then read the jobs

Once you know the platform, it's one call:

# Greenhouse
requests.get("https://boards-api.greenhouse.io/v1/boards/stripe/jobs?content=true").json()["jobs"]

# Lever
requests.get("https://api.lever.co/v0/postings/spotify?mode=json").json()

# SmartRecruiters (paginated, 100 per page)
requests.get("https://api.smartrecruiters.com/v1/companies/Visa/postings?limit=100").json()["content"]

Ashby is an unauthenticated GraphQL POST. Workday is a POST too, and it has one trap that costs everybody a day: limit cannot exceed 20. Ask for 100 and it returns an empty array rather than an error, which looks exactly like "no more results." It also throttles fast paging, so if your loop treats a failed page as the end of the list, you'll silently collect a fraction of the jobs.

Don't guess the slug

The board token in those URLs is not the company name. It's whatever the company typed when they set up the account. Read it off the real careers URL rather than guessing.

I learned this the tedious way: guessing slugs across those 42 employers had roughly a 10% hit rate, and two of the "hits" were the wrong company entirely. One slug belonged to a New York firm that happened to share a name fragment with the company I wanted. Another belonged to an education company rather than the marketplace with a similar name.

Always print the locations of the jobs you get back before you trust that you found the right board.

The no-code version

I packaged all five platforms into a free scraper: it auto-detects the ATS, normalizes the payloads into one schema, and adds seniority and function detection. Free, because these APIs need no proxies and cost nothing to call.

All my scrapers are here — the ATS one is free to run.

The code is open source under MIT if you'd rather read it than run it.

Be reasonable about it

These endpoints are public because companies want their jobs found. Cache your results, pause between requests, and don't hammer a small company's board on a cron. The reason all of this works without keys is that nobody has yet had a reason to lock it down.

How to Scrape GCC Job Salaries from Indeed & Glassdoor (UAE, Saudi & the Gulf)

Get Anything — Mon, 27 Jul 2026 11:23:12 +0000

Salary data is the hardest part of Gulf job data to get — and the most valuable. Most GCC job boards (Bayt, GulfTalent, NaukriGulf) rarely publish pay. The two sources that do — Indeed and Glassdoor — sit behind Cloudflare and aggressive anti-bot protection, so a normal scraper just gets a "Security Check" page.

Here's how to pull structured Gulf jobs *with salary* from both, across the UAE, Saudi Arabia, Qatar, Kuwait, Bahrain and Oman — reliably.

Why Indeed and Glassdoor are worth the trouble

Indeed exposes a real salary range on a large share of GCC listings (often 70–80%), plus employment type, remote flag and even a company rating.
Glassdoor shows employer-provided salary ranges and company data that nothing else in the region matches.

If you're doing salary benchmarking, recruitment intelligence, or building a jobs product, this is the data that makes it credible.

The blocker — and how it's solved

Both sites use Cloudflare's "Just a moment…" challenge. Standard HTTP clients (and even patched headless browsers) only get through intermittently. The reliable fix is a hardened, fingerprint-spoofing browser that passes the challenge the way a real visitor does. That's already built into these two ready-made tools:

👉 Indeed Scraper — GCC Jobs, Salaries & Employers
👉 Glassdoor Scraper — GCC Jobs & Salary Data

Give each a keyword and one or more countries, and get back structured jobs with salary, location, company and apply links.

Example (Indeed) output

{
  "title": "Senior Accountant",
  "company": "Pure Water Technology",
  "companyRating": 3.4,
  "city": "Abu Dhabi",
  "country": "United Arab Emirates",
  "employmentType": "full-time",
  "salaryText": "AED 5,000 - AED 8,000 a month",
  "salaryMin": 5000,
  "salaryCurrency": "AED",
  "link": "https://ae.indeed.com/viewjob?jk=..."
}

Use it inside ChatGPT or Claude

Both tools are AI-ready via the Apify MCP server. Connect the Actor and ask in plain language:

"Find accountant jobs in Dubai paying over AED 10,000 a month."

"What do finance roles in Riyadh pay?"

Want the whole GCC job market in one query?

If you care about coverage more than salary specifically, start with the free flagship:

👉 GCC Jobs Search — free — searches Bayt, GulfTalent, NaukriGulf, Foundit and Tanqeeb together, with filters for field, experience, city, salary and company, and full recruitment-agency coverage. Then layer Indeed/Glassdoor on top for salary depth.

Common use cases

Salary benchmarking by role, city and country
Recruitment intelligence — who's hiring, at what level, for how much
Job boards & aggregators that need salary-enriched listings
Market research on Gulf hiring and compensation trends

Legitimacy

These read public search pages — the same pages any visitor sees — with no login and no paywall bypass.

Tools: Indeed GCC Scraper · Glassdoor GCC Scraper · GCC Jobs Search (free). Part of a suite of Gulf-focused public-data tools by Get Anything.

How to Get Dubai Land Department (DLD) Transaction Data — Free, No API Key

Get Anything — Mon, 27 Jul 2026 11:23:11 +0000

If you invest in, sell, or analyse Dubai real estate, you already know the problem: portals like Bayut and Property Finder show you what sellers are asking. They don't show you what buyers actually paid. For any real decision — a valuation, a rental-yield model, a market report — you need registered transaction data from the Dubai Land Department (DLD).

The DLD publishes this data. The catch is that the official formats (an OAuth-protected API and login-gated bulk CSVs on Dubai Pulse) take real engineering effort to use. Below is the simplest way to pull it into clean, structured JSON — with no personal API key and no login.

What DLD transaction data actually contains

The DLD registers every sale, mortgage and gift in Dubai. Aggregated by area, the public data gives you, for any date range:

Community (Dubai Marina, JVC, Business Bay…) and project
Property type & sub-type (Unit/Flat, Villa, Land…)
Sale sequence — first sale (usually off-plan) vs resale
Transaction count, total value (AED) and total size (sqm)
Price per square metre — the single most useful benchmarking metric
Everything bilingual (English + Arabic)

This is the ground truth behind the asking prices. A 1-bed in JVC might be listed at AED 1.2M, but the DLD data tells you the average first-sale price there was AED ~1.05M at ~AED 16,200/sqm last month, while resales ran cheaper per sqm.

The fastest way to pull it: the DLD Transactions Actor

Instead of wrangling OAuth tokens and 300 MB CSVs, you can use a ready-made tool on Apify:

👉 Dubai DLD Transactions Scraper

You give it three things:

Transaction type — Sales, Mortgages or Gifts
From date and To date (YYYY-MM-DD) — history goes back years

…and it returns one clean record per community × sub-type × sale sequence, with pricePerSqmAed, avgTransactionValueAed, avgSizeSqm, transactionCount and totalValueAed. Run it from the Apify Console, via API, on a schedule, or as an AI tool inside ChatGPT/Claude ("what was the average price per sqm in Dubai Marina this month?").

Example output

{
  "community": "JUMEIRAH VILLAGE CIRCLE",
  "communityAr": "جميرا فيليج سيركل",
  "propertySubType": "Flat",
  "saleSequence": "First",
  "transactionCount": 118,
  "avgTransactionValueAed": 1051387.56,
  "pricePerSqmAed": 16218.46,
  "fromDate": "2026-07-01",
  "toDate": "2026-07-31"
}

What you can build with it

Price benchmarking — real AED/sqm by community, this month vs last year
Rental yield / ROI models — pair sold prices with asking rents
Off-plan vs ready market share (first-sale vs resale split)
Market reports & dashboards that quote registered prices, not seller hopes
Valuation models grounded in actual comparables

Pair it with asking-price data

The complete picture is asking vs sold. Combine the DLD data with live listings from the Bayut Property Scraper (price, beds, baths, area, agent) to see the gap between what's listed and what's transacting in the same community.

A note on legitimacy

This uses public government data — the same figures the DLD publishes on its own transactions page for every visitor. No login, no scraping of private records, no paywall bypass.

Get the tool: Dubai DLD Transactions Scraper on Apify. Part of a suite of Gulf-focused public-data tools by Get Anything.