White-label ride-hailing platform

One platform.
Every brand.
Configured per tenant.

Waslni combines an Arabic-first mobile experience, 48 supported languages, tenant configuration, regional payment integrations, and a launch plan scoped to your market.

Three phones running the same ride-hailing app in different brands and languages
1
Shared product with tenant-specific configuration
48
Supported languages, including Arabic and Hebrew RTL
Role-aware
One app for riders, drivers, shops, and authorized staff
Scoped
Launch plan based on market dependencies
Last updated · May 202610 min readWhite-label platform

White-label is one of the most abused words in B2B software. It usually means a re-skin — same product, different colour, same vendor name buried in the footer of a receipt PDF.

That definition was good enough when the product was a salon booking calendar. It is not good enough when the product is a ride-hailing service that has to settle thousands of payments per day, dispatch drivers in real time across a city, file VAT in two currencies, and absorb the unique fact that one of your drivers just had their car towed. A real white-label ride-hailing platform has to do the boring parts of being a marketplace operator out of the box.

Waslni is built around two product decisions. First, operators use a maintained hosted platform rather than maintaining a separate fork of the codebase. Second, tenant configuration reaches into service types, fares, peak hours, document requirements, registration fields, permissions, policy content, and App Experience so routine operating changes stay under the operator’s control.

Four pillars

What 'white-label'
actually means
when you ship it

Most platforms claim white-label and ship a re-skin. These are the four lines that separate a real white-label platform from one.

01

It is genuinely your brand

Logo, palette, app name, bundle ID, deep-link host, splash colour, push sound, store metadata, marketing email templates — all per-tenant variables. Two Waslni-powered apps will not look like siblings unless their operators want them to.

02

Admins change product behaviour, not engineers

Service types, fares, peak windows, driver document checklist, registration form fields, role permissions, banners, terms of service, OTP providers — all editable from the dashboard. Engineering ships product, not config tickets.

03

Arabic is a first-class language

The customer and driver experiences support right-to-left Arabic alongside seven other bundled languages. Tenant-authored labels and content can be managed by language from the dashboard.

04

Regional payments are configurable

The provider catalog includes Lahza for Palestine and Fawry, Kashier, and Paymob for Egypt. Operators enable the methods available in their country and choose whether each method serves customers, drivers, or both. Cash and wallets are supported too.

What the platform includes

A complete
ride-hailing stack

One connected product stack: a unified mobile app, a quick in-app admin area, and a full web control panel, all backed by the same tenant configuration.

Mobile

One app for riders and drivers

Customers request rides, browse shops, order delivery, use their wallet, and review history. Approved drivers switch the same account into driver mode for jobs, navigation, earnings, wallet, and document workflows. One install replaces separate rider and driver apps.

In-app admin

Quick operations from the phone

Permission-aware admins can search users, review drivers, follow orders and withdrawals, manage shops and coupons, send notifications, and open the live command center without leaving the mobile app.

Web admin

Full dispatch + configuration

The browser dashboard adds live dispatch, analytics, service and pricing editors, App Experience controls, driver-registration forms, payment methods, roles, content, marketplace layout, and audit history.

Platform features

What is in the box

The features below are not on a roadmap. They are running in production for two operators in two countries today.

Multi-tenant

Run one brand or many

Tenant context selects the correct database, Redis namespace, and operating configuration. In multi-tenant mode, authenticated tokens also carry a tenant claim that must match the tenant resolved for the request.

Permissions

Real role-based access

Super Admin, Admin, Manager, Customer Service out of the box, each with a granular permission registry. Build custom roles by toggling permissions. Audit log captures who changed what.

i18n

48 supported languages, with content control

Policy, terms, rules, and onboarding copy are managed through the content system. Your team writes the text for the languages used by its deployment, and the app renders the appropriate version for the user.

Compliance

Driver identity and document workflows

Compose driver-registration sections and required fields by service type, including identity, licence, vehicle, insurance, image, text, select, year, colour, and vehicle-model inputs. The mobile flow follows the saved configuration.

Onboarding

Self-serve driver registration

Drivers register from the app, upload documents, and your team reviews from the admin panel. The form is admin-composable: add new fields by type (image, text, select, color, car model) without shipping code.

Releases

OTA updates where technically eligible

JavaScript-only changes can use Expo EAS Update. Changes that add or modify native code still require a new binary and store review.

Buy vs. build

Generic SaaS vs.
Waslni

Most ride-hailing SaaS started in another region and was retrofitted to MENA. Waslni was built where the operators are.

Feature
Generic ride-hailing SaaS
The category average
Waslni
MENA-first, hosted, configurable
Hosted vs. you-host-it
You host
We host (multi-region)
Per-tenant config without code
Limited
Yes — service types, fares, docs, forms, roles, content
Arabic UI in app + admin + emails
Partial
Full
Supported MENA payment integrations
Configured per tenant
Multi-tenant (one cluster, many brands)
One white-label app in your stores
Sometimes
Yes — your developer accounts
Shared product update model
Varies by vendor
Single codebase; OTA where eligible
Launch planning
Varies by scope
Scoped around market dependencies
Launch timeline

Four stages.
One controlled launch.

The sequence is consistent, but the duration depends on brand assets, developer accounts, gateway approval, local licences, testing, and store review.

01 /
Step 1

Brand + tenant setup

Confirm the app identity, tenant configuration, currency, default language, domain, storage, and administration access.

02 /
Step 2

Operating configuration

Configure service types, fares, peak windows, driver registration, service areas, permissions, and App Experience.

03 /
Step 3

Payments + local requirements

Connect supported gateways through your merchant accounts and complete local licensing, privacy, and legal review.

04 /
Step 4

Controlled pilot + store submission

Test the configured flow with a controlled pilot, resolve findings, then submit the production binary through your developer accounts. Store approval remains outside the platform’s control.

Questions operators ask

Honest answers.
Not sales answers.

01 /

What does "white-label" mean on Waslni?

It means one mobile app is published in the App Store and Google Play under your developer accounts, with your name, logo, colours, and bundle ID. That app contains rider and driver modes and can also expose shop-owner and permission-aware admin tools. The full web dashboard sits on your operating domain.

02 /

Can I launch rides only, delivery only, or both?

Yes. Settings → App Experience includes Ride-only, Delivery-only, Ride-first, Delivery-first, and Both presets. You can enable Transport, Marketplace, and Wallet independently, choose the opening module, and localise the module labels.

03 /

How is this different from buying an Uber clone?

A clone script usually transfers the maintenance burden to the buyer. Waslni is hosted: the shared platform is maintained centrally, while each operator manages its own brand, configuration, data, and daily business.

04 /

Can I edit fares and service types without engineers?

Yes. The admin panel has dedicated editors for service types (car, taxi, van, motorcycle, custom), pricing formulas per service type and per city, peak-hour multipliers with multiple windows per day, and seat-count rules. Changes take effect immediately.

05 /

Which payment gateways are currently supported?

The platform integrates Lahza for Palestine and Fawry, Kashier, and Paymob for Egypt. Activation depends on the tenant’s merchant account and configuration. Any other gateway or country requires a separate technical and commercial review.

06 /

Do you support Arabic in the admin panel too?

Yes. Every admin screen is fully translated and rendered right-to-left when the operator picks Arabic. Email and SMS templates are bilingual. Print receipts render correctly in Arabic.

07 /

What about the source code? Do I own it?

Waslni is hosted SaaS, so the platform source code is not transferred. Your agreement should state the ownership and export terms for your data, brand assets, tenant configuration, accounts, and published app listings.

See it for yourself

A real demo tenant,
ready to explore

14 days free. The unified app installs on your phone, and the full admin panel opens in your browser. No card required.

White-label ride-hailing platform — Waslni