Waslni is a maintained, MENA-focused white-label platform rather than a one-time clone-script handover. It combines one role-aware mobile app, permission-aware in-app operations, a full web admin panel, and configurable rides and delivery experiences.
Most people searching for an "Uber clone" are not actually looking for an Uber clone. They are looking for a way to start a ride-hailing business without writing the platform from scratch. The clone-script market showed up to answer that question with a $4,999 license to a recycled codebase. It mostly does not work.
The core problem is that ride-hailing is a live marketplace, not a static app. It needs reliable assignment, safety workflows, payments, driver onboarding, permissions, settlement records, store compliance, and ongoing maintenance. A code handover does not remove those operating responsibilities.
Waslni takes a maintained-product approach. Operators configure each tenant down to service types, fare rules, driver-registration fields, permissions, content, payments, and App Experience, while the platform provides the shared mobile and backend foundation.
isCash.The right evaluation is not whether a demo screen looks convincing. Check the complete operating flow: rider and driver modes, dispatch, onboarding, permissions, payments, settlement, support, updates, data export, and who remains responsible after launch.
Every behaviour a rider would experience in Uber or Careem, shipped under your brand.
Customers choose pickup and destination, review the estimated fare, select an enabled payment method, request the trip, and follow its status from the same mobile app.
In-app SOS calls the local emergency number and notifies your operations team. Share-ride sends a live tracking link by SMS or WhatsApp. Riders see the driver photo, rating, plate number, and ID before pickup.
Cash and wallet flows are built into the product. Supported gateway integrations include Lahza for Palestine and Fawry, Kashier, and Paymob for Egypt; activation depends on the tenant’s merchant account and configuration.
Built-in referral codes with admin-defined rewards. Promo codes per city, per service type, per first-N-rides. Bonuses settle to rider wallet or as a fare discount.
A focused driver mode for availability, incoming work, navigation, earnings, wallet activity, and the registration requirements configured by the operator.
The driver switches availability, receives work supported by the enabled services, accepts or declines requests, navigates to pickup and destination, and completes the job from driver mode.
Drivers can review trip earnings, commission effects, and wallet activity. The operator uses web reports and settlement records to run the business’s chosen payout process.
The enabled service catalog and the driver’s approved registration data determine which ride or delivery work is available to that account.
Admins build registration sections and fields, choose service-type visibility, and review submitted text, selections, vehicle details, and images without relying on a fixed document list.
Dispatch, finance, drivers, riders, content, branding — one panel, with permissions so you can scale the team without scaling chaos.
Operators see every active driver and every active order in real time. Phone-booking shortcut for call-in customers. Manual reassignment for the awkward 1% of cases. Trip-history filter for follow-up.
Super Admin, Admin, Manager, Customer Service — each with a permission registry. Lock down who can edit fares, who can refund a rider, who can suspend a driver. Audit log records every change.
Sedan, taxi, van, motorcycle, custom. Per-type pricing formula (per-km + per-min + base fare + minimum fare). Per-type peak-hour multipliers. Seat counts. All editable from the admin panel.
Revenue reporting can be filtered by service type, city, and payment method. Driver commission and settlement records support the operator’s reconciliation workflow and can be exported for further review.
Privacy, terms, rules, FAQ pages are editable from the admin panel. Multi-language. No deploy required to update copy.
Each tenant has its own app identity and brand configuration. App Experience can be rides-first, delivery-first, rides-only, delivery-only, or both, while rider and driver accounts still use the same mobile app.
A clone-script demo can look convincing in a screenshot. A real service must handle live demand, account roles, payments, driver workflows, and operational failures. These are the parts that matter.
Tenant context selects the correct database and Redis namespace. In multi-tenant mode, authenticated tokens also carry a tenant claim that must match the resolved tenant.
Authenticated endpoints verify the user token, while admin routes add permission checks from a central registry. The interface also hides actions the current role is not allowed to use.
The web admin panel brings together trips, drivers, service settings, finance records, roles, content, and day-to-day operational controls so issues can be investigated from one place.
The honest comparison, with the trade-offs called out plainly.
Not in the clone-script sense. Waslni is a hosted multi-tenant platform with one branded mobile app that changes by account role, quick permission-aware operations inside the app, and a full web admin panel. It can run rides, marketplace delivery, or both under your identity.
Because the buyer inherits maintenance, security updates, store-policy changes, payment changes, and any gaps between the demo and the full operating workflow. Review the actual architecture, support terms, update policy, and data ownership before buying any codebase.
Commercial terms depend on the selected package, operating scope, and any requested work. Payment-processing fees and merchant-account terms come from the chosen gateway. Use the demo and proposal to confirm the exact scope before committing.
Yes. Operators can configure service types and fares, peak windows, driver documents and registration fields, permissions, banners, shop layout, policy pages, and App Experience. Deeper product changes require separate scoping and may need a new binary when native code is involved.
Confirm data ownership, export formats, published-app ownership, and transition support in the service agreement. The exact export scope should be documented before launch rather than assumed from a marketing claim.
Capacity depends on traffic shape, geography, infrastructure, and operational requirements. We review the expected launch load and growth plan with each operator instead of publishing an unverified universal trip limit.
Explore the unified rider-and-driver app, its permission-aware operational tools, and the full web admin panel in the demo environment.