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” want a faster route to operating a ride-hailing business. The phrase covers very different products: a code handover, a custom build, or a maintained hosted platform. The purchase decision should be based on responsibilities and demonstrated workflows, not the label.
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.
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.
The demonstrated Waslni rider journey under your brand, with tenant-specific services, fares, and enabled payment methods.
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.
Rider and driver SOS flows record an alert for the operations team and open a prepared WhatsApp message to the saved emergency contact with available location details. Review the exact profile and vehicle details shown before pickup in the live tenant.
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.
The product includes referral and promotion workflows. Confirm the current eligibility rules, reward destination, service restrictions, and accounting treatment in the configured tenant.
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 can review active drivers and orders, create phone bookings, manually reassign supported cases, and use trip history for follow-up. Demonstrate the exact filters and recovery actions your team needs.
Super Admin, Admin, Manager, and Customer Service permissions come from a central registry. Grant sensitive actions deliberately and verify which administrative events are included in audit history.
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 sales demo is only one input. Verify how the product handles live demand, account roles, payments, driver workflows, and operational failures in the current environment and written scope.
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.
Risk depends on the actual deal. A code handover can leave maintenance, security updates, store-policy changes, payment changes, and workflow gaps with the buyer; a hosted agreement allocates them differently. Review the architecture, support terms, update policy, and data ownership before committing.
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.