How a MENA Food-Tech Startup Built Its F&B Intelligence Product on Talabat, HungerStation & Jahez Data

Introduction

3

platforms, unified into one schema

120K+

restaurant-menu snapshots per refresh

Project → SaaS

same data layer, no rebuild at scale

Client: MENA F&B analytics startup (name withheld)

Industry: Food Delivery Intelligence

Use Case: Menu, pricing, promotion & review intelligence

Coverage: Talabat (multi-country), HungerStation & Jahez (Saudi Arabia)

Delivery: Scheduled JSON via API + CSV exports; per-platform pricing

About the Client

Our client is a food-tech startup building analytics for the MENA F&B market — helping restaurant brands, cloud kitchens and investors understand what sells, at what price, with what promotions, across the region's dominant delivery platforms. The founding team began with a consulting-style project for early customers, with a clear plan: if the insights proved valuable, productize them into a SaaS platform.

That plan put an unusual demand on the data layer from day one — it had to be priced and structured like a project, but architected like a product.

The Challenge

• Three platforms, three worlds. Talabat, HungerStation and Jahez differ in structure, language handling (Arabic/English mixed menus), geography logic and how they surface promotions. Building three reliable collectors — app-first, actively protected platforms — was months of engineering the startup didn't have.
• The data needed depth, not just listings. The product's value came from item-level detail: full menus, item prices, active promotions and discount mechanics, ratings, review text, and delivery-time signals — per restaurant, per city zone.
• Cost transparency mattered. As a startup, the team needed to understand pricing per platform and per refresh cadence before committing — and needed the model to survive a 10x scale-up without renegotiating from scratch.
• Scheduled today, real-time tomorrow. Early customers were fine with weekly snapshots; the SaaS roadmap needed daily and eventually near-real-time refresh on promotions — without a data-layer rebuild in between.

The Actowiz Solution

1. One Schema Across Three Platforms

We built per-platform collectors that normalize into a single restaurant → menu → item schema, with bilingual (Arabic/English) fields preserved side by side. The client's analytics code never touches platform quirks — a Jahez menu and a Talabat menu are the same shape.

2. Promotion Mechanics, Decoded

MENA delivery platforms run layered offers — percentage discounts, item-level deals, basket thresholds, platform-funded vs restaurant-funded promos. Our extraction captures the offer text and a parsed structure (type, value, conditions), because "promotion intelligence" was the client's headline feature.

3. Zone-Level Coverage

Availability, delivery time and even assortment vary by delivery zone. Crawls anchor to defined zones in each covered city, so the client can answer "what does a customer in North Riyadh actually see?" — not a city average.

4. A Pricing Model Built for a Startup's Curve

We structured commercials per platform and per refresh tier: weekly snapshots at project stage, with pre-agreed pricing steps to daily and intra-day refresh. When the client's SaaS launched, scaling the cadence was a config change and a PO — not a re-procurement.

The Results

• 3-in-1 a single normalized feed replaced what would have been three separate in-house scraping projects — the startup's engineers built product, not collectors
• 120K+ restaurant-menu snapshots per refresh cycle across covered cities, with item-level promotion parsing as a first-class field
• Weeks, not quarters from signed scope to first client-ready dataset — the founding team demoed real regional insights to design-partner customers within the first month
• No rebuild the same schema and API carried the client from weekly project snapshots to daily SaaS refresh — the scale-up was commercial, not technical

Client Feedback

"We asked every vendor the same four questions — cost per platform, pricing model, refresh options, delivery format. Actowiz was the only one whose answers were specific enough to put in our investor deck."

— Founder, MENA F&B analytics startup

Why It Worked

• Normalize early. One schema across platforms is what made a SaaS product possible on top — analytics written once, applied to every platform.
• Parse the promos. Raw offer strings are trivia; structured promotion mechanics are a product feature. Knowing which the client was selling shaped the extraction spec.
• Price for the journey. Startups don't need the cheapest pilot — they need a cost curve they can model. Pre-agreed scale tiers removed the biggest procurement risk.

Frequently Asked Questions

Which MENA platforms and countries do you cover?

Talabat across its GCC markets, HungerStation and Jahez in Saudi Arabia, plus Careem Food, Snoonu (Qatar), Deliveroo and regional grocery/q-commerce platforms. Coverage notes per country are shared before scoping.

How is Arabic content handled?

Bilingual fields are preserved as published (Arabic and English side by side); optional transliteration/translation columns can be added for analytics teams working in one language.

Real-time or scheduled — what do clients actually use?

Most start with daily or weekly snapshots for menus and reviews, adding higher-frequency refresh only on promotions and availability, where change velocity justifies the cost.

Is this compliant?

We collect only publicly displayed restaurant, menu, pricing, promotion and review information — no user accounts and no personal data. Collection follows our published compliance framework.