Start a local delivery app
with an operating plan
before a growth plan
Choose one customer problem, map the money and fulfilment flow, launch in a serviceable area, and expand only after the operation produces evidence you can trust.

A local delivery app is not the business by itself. The business is the promise you can repeatedly fulfil: the right item or parcel, collected by the right person, delivered to the right place, with the money and responsibility traceable from end to end.
Begin with a narrow statement: who needs what moved, within which area, under what service conditions? Parcels, restaurant meals, groceries, and pharmacy orders look similar on a map but create different merchant, handling, timing, substitution, compliance, and support requirements.
Waslni can support delivery only, food or shops only, rides only, or a combined model. Depending on the scope, that can include a customer app, courier or driver app, merchant and vendor operations, admin and dispatch, live tracking, payments, coupons, and menus or catalogs. Configuration does not replace the operating choices described in this guide.
Similar maps.
Different businesses.
Select the category whose demand, supply, handling requirements, and commercial relationships you can operate—not simply the category with the broadest headline market.
Point-to-point delivery
Useful for documents, gifts, small business orders, and same-day local movement. Define prohibited goods, size and weight rules, sender handoff, recipient proof, returns, and failed-contact policy.
Restaurant marketplace
Requires menu accuracy, modifiers, merchant acceptance, preparation timing, heat-sensitive handoff, courier coordination, and rapid support when an order changes.
Catalog and picking
Adds inventory uncertainty, substitutions, weighted items, picking ownership, larger baskets, scheduled windows, and careful handling. Decide whether the store, your picker, or the courier prepares the basket.
Health-related fulfilment
May involve regulated items, prescription checks, age or identity verification, privacy, controlled substitutions, handling conditions, and market-specific legal requirements. Obtain local professional advice before launch.
Focused service
or multi-service app?
A super app is a sequencing decision, not a launch slogan. Start with the scope your team can supply, explain, support, and measure.
| Operating question | Focused single service | Combined or super app |
|---|---|---|
| Customer proposition | One specific job with a simple promise and clearer acquisition message | Several local mobility and commerce jobs under one account and brand |
| Supply setup | One courier profile, merchant type, or delivery workflow to recruit and train | Potentially different drivers, couriers, merchants, eligibility, equipment, and availability rules |
| Operational complexity | Fewer states, policies, support playbooks, and settlement relationships | Shared platform with service-specific pricing, dispatch, catalogs, support, and financial logic |
| Cross-service value | Limited initially; depth and reliability are the priority | Customers and supply may use more than one service when the local need and operations support it |
| Best starting condition | A clear pain point, constrained team, or unproven market | Existing demand or supply across services, strong operations, and a deliberate rollout sequence |
| Waslni deployment | Launch delivery only, food or shops only, or rides only | Combine rides, delivery, food, and shops under the configured brand and operating model |
Model one completed order
before forecasting thousands.
Use quotes and observed operating data from your market. Avoid imported averages and invented targets; model ranges, then replace assumptions with launch evidence.
Define the unit and segment
Use a completed order or delivery as the base unit, then segment by service, zone, distance band, merchant type, payment method, time window, and new versus repeat customer. Blended averages can hide an unworkable segment.
List revenue attached to the order
Include the customer delivery or service fee, merchant commission where applicable, basket markup only if transparent and lawful, subscription allocation, and other contracted revenue. Keep taxes and pass-through amounts separate.
Calculate courier fulfilment cost
Model base pay, distance or time components, waiting, return trips, failed delivery, peak adjustments, guarantees, incentives, equipment, insurance, and any employment or contractor obligations that apply locally.
Add transaction and exception costs
Include payment processing, cash handling, refunds, redelivery, customer credits, damaged or missing goods, chargebacks, communications, maps, and variable support effort attributable to the order.
Treat promotions as a cost
Separate customer coupons, merchant-funded discounts, courier incentives, referral rewards, and free-delivery campaigns. Attribute each subsidy to the party funding it and the behaviour it is meant to change.
Calculate contribution before overhead
Add order-level revenue, then subtract courier fulfilment, payment, promotion, refund, exception, and other variable order costs. Review contribution by segment before allocating salaries, offices, and general platform overhead.
Connect economics to service quality
Track completion, lateness, merchant acceptance, courier waiting, reassignment, support contact, refund, and repeat behaviour beside contribution. A margin created by poor fulfilment will not persist.
Prove the operation
one boundary at a time.
Each step produces an artifact or decision the next step depends on. Keep the launch small enough that your team can inspect failures closely.
Interview both sides of the market
Speak with target customers and the merchants, senders, couriers, or drivers needed to fulfil the service. Observe current workarounds, frequency, urgency, trust concerns, and willingness to change—not only stated interest.
Write the service promise
Define the first category, service area, operating hours, delivery conditions, exclusions, support channel, and what “completed” means. Make the promise precise enough to train against.
Build the unit model
Collect local quotes and contract terms for courier pay, payments, merchants, insurance, support, mapping, communications, and exceptions. Create conservative, expected, and favourable cases without pretending any case is guaranteed.
Design zones and dispatch rules
Map pickup density, destinations, roads, barriers, parking, peak periods, and courier availability. Set assignment, reassignment, waiting, batching if used, and manual dispatch rules.
Secure launch supply
Recruit the initial merchants, couriers, drivers, or business senders. Verify documents, commercial terms, catalogs or menus, hours, capacity, equipment, and at least one trained operator for each partner workflow.
Configure the operating platform
Apply your brand, service types, roles, fees, payments, coupons, menus or catalogs, notifications, dispatch, tracking, and support access. Integrate only what the launch workflow actually requires.
Run an exception-heavy pilot
Test successful delivery plus payment failure, unavailable goods, address changes, no courier, late pickup, customer no-show, cancellation, refund, cash mismatch, return, and support escalation.
Launch narrowly and review weekly
Open to a controlled zone and audience. Review demand, supply, fulfilment states, unit contribution, support causes, retention, and partner feedback. Expand a boundary only when the underlying constraint is understood.
Add scope when the evidence
earns the complexity.
Growth should strengthen the operating system. If a new zone or service hides unresolved failures, it creates volume without a dependable business.
Core fulfilment is stable
Completion and timing are consistent enough to explain, recurring exception causes are reducing, and support can resolve the remaining cases with clear ownership.
Capacity is visible by zone
You understand when and where courier or driver supply is constrained, what recruitment changes it, and how added demand will affect waiting and service quality.
Contribution is understood
You can explain contribution and its drivers by service and zone, distinguish temporary subsidies from durable revenue, and see how growth changes variable costs.
The team can absorb change
Dispatch, merchant operations, finance, and support have documented playbooks, useful data, and enough capacity to add a service or area without abandoning the core.
Practical questions
before launch.
Which delivery category should I start with?
Start with the category where you can verify recurring demand and reliably assemble the required supply, handling, support, and commercial relationships in a compact area. Choose from local evidence, not from the apparent size of a global category.
Do I need a super app from day one?
No. A focused service often creates a clearer promise and a simpler operation. A combined app makes more sense when you have real cross-service demand or supply, sufficient operational control, and a deliberate sequence for introducing each service.
How do I estimate delivery unit economics?
Model each completed order using local inputs: customer and merchant revenue, courier fulfilment, payment cost, discounts, incentives, refunds, exceptions, communications, maps, and variable support. Segment the result by service, zone, distance, time, and payment method, then replace assumptions with pilot data.
What technology does Waslni provide?
Depending on configuration, Waslni can provide customer, courier or driver, merchant or vendor, admin, and dispatch experiences with real-time tracking, payments, coupons, menus, and catalogs. It can launch rides only, delivery only, food or shops only, or combine them.
What must be settled before a pharmacy delivery launch?
Identify the locally applicable rules for medicines, prescriptions, identity or age checks, privacy, substitutions, storage, transport, records, and professional oversight. Obtain qualified legal and pharmacy guidance in the market; software configuration is not regulatory approval.
Related operator guides
Build a food marketplace for MENA
Plan the customer, restaurant, courier, and operator model with Arabic-first execution.
Read the guideWorkflow guideDesign the complete food order lifecycle
Map merchant preparation, courier assignment, tracking, support, and build-vs-buy choices.
Read the guideProduct scopeExplore a multi-service Waslni launch
See how rides, delivery, food, and shops can share one configured platform.
Read the guideConfigure the first service,
then learn from real orders.
Explore Waslni for delivery, food, shops, rides, or a staged combination—with the operational apps and controls behind the service.