01 /
Is a fixed seven-day pilot required?
No universal duration fits every operator. Define the pilot by coverage, users, scenarios, and acceptance evidence, then extend it if material risks remain.
Pre-launch checklist
Review the evidence,
assign the owners
then decide to launch.
Validate the real configuration—unified app, selected modules, administration, payments, drivers, support, and legal responsibilities—before public expansion.
8 areas
Product, operations, compliance, and launch readiness
One app
Test rider and driver roles in the same build
App Experience
Confirm rides, delivery, shops, or a combined scope
Go / no-go
Launch only when owners accept the evidence
8 areas
Product, operations, compliance, and launch readiness
One app
Test rider and driver roles in the same build
App Experience
Confirm rides, delivery, shops, or a combined scope
Go / no-go
Launch only when owners accept the evidence
Last updated · July 202610 min readLaunch checklist
A pre-launch checklist is useful when every item has an owner, evidence, and a clear acceptance decision. It should not assume gateways, refunds, bank payouts, regulatory exports, or support SLAs that may not exist in a particular deployment.
Test Waslni as it is actually configured: one mobile app with rider and driver roles, quick administration inside the app, the full web dashboard, and the modules selected through App Experience.
Run a limited pilot, record defects and operating gaps, and let the accountable product, operations, legal, finance, and support owners make the final go/no-go decision.
Eight review areas
Evidence before launch,
not assumptions
Adapt every check to the country, operator, enabled modules, and integrations in the deployed configuration.
01 /
Area 01
Unified app and store release
Test rider and driver accounts in the same production candidate. Verify role switching, onboarding, permissions, links, notifications, privacy pages, store text, and supported devices.
- Rider and driver journeys pass on supported devices
- The build belongs to the correct brand and store account
- Deep links and notifications are tested
- A rollback and support path is documented
02 /
Area 02
App Experience and service scope
Confirm exactly which modules are visible: rides only, delivery or shops only, or a combined super-app. Check service types, seat counts, pricing, zones, and customer content.
- Hidden modules are not exposed accidentally
- Every visible service has an owner and operating process
- Prices are checked against the approved rules
- Test accounts see the expected home experience
03 /
Area 03
Enabled payment methods
Test only the payment providers and cash flows actually configured for this operator. Record success, failure, cancellation, webhook, refund, and reconciliation behaviour where supported.
- Merchant credentials belong to the operator
- Test transactions appear in the expected systems
- Failure messages are understandable
- Finance signs off the available reconciliation data
04 /
Area 04
Drivers, vehicles, and registration
Complete the dynamic registration flow with realistic data. Review required fields, service-specific sections, uploaded documents, approval, and the submit-for-review gate.
- No legacy hard-coded document list reappears
- Required fields match the local operating decision
- Reviewers can approve and reject correctly
- Pilot drivers know the support route
05 /
Area 05
Legal and security responsibilities
Confirm local transport licensing, insurance, tax, privacy, data handling, terms, and incident contacts with qualified advisers. WASLNI LTD is the software provider, not the local transport licensee.
- Local operator details are correct
- Policies match enabled services and payments
- Access follows least privilege
- Secrets and production credentials are controlled
06 /
Area 06
Administration and permissions
Test quick administrative tasks inside the app and full configuration on the web. Verify every staff role against real job responsibilities.
- Navigation respects permission keys
- Sensitive actions are limited to authorised roles
- Driver and registration review works end to end
- Reports are described only as they actually exist
07 /
Area 07
Customer and driver communications
Prepare onboarding, payment-failure, cancellation, outage, safety, and escalation messages in the languages used by the operation. Test support ownership, not arbitrary response-time claims.
- Messages name the correct brand and contact channel
- Arabic and English meaning is reviewed by humans
- Escalation owners are reachable during the pilot
- Known limitations are explained honestly
08 /
Area 08
Pilot, monitoring, and go/no-go
Run a controlled pilot and review completed rides, failed bookings, driver availability, payments, support cases, and technical incidents before expanding.
- Blocking defects have owners and decisions
- Fallback steps are rehearsed
- Operations, finance, support, and legal sign off
- Expansion criteria are based on observed results
Launch questions
Clear answers
for accountable teams
02 /
Should we test separate rider and driver builds?
No. Waslni uses one role-aware app. Test both roles thoroughly in the same release candidate.
03 /
What should App Experience validation cover?
Confirm whether the tenant exposes rides only, delivery or shops only, or both, and verify that every visible module has services, content, staff, and support ready.
04 /
Does this checklist certify legal compliance?
No. It organises questions and evidence. Qualified local advisers and the operator remain responsible for licensing, insurance, tax, privacy, and sector rules.
05 /
Who decides whether to launch?
The accountable operator owners for product, operations, finance, support, security, and legal should make and record the go/no-go decision.
Prepare the pilot
Use the checklist with,
your actual configuration
Open a demo, select the App Experience, test both mobile roles, and review the full administration workflow.