Developing a Mobile App for Goods Delivery
Goods delivery differs from food delivery in several fundamental ways: goods can be large and heavy (affecting tariff calculation), delivery time measured in intervals ("2-4 PM"), often needs signature on receipt or content verification. Most importantly—merchandise catalog and warehouse logic usually integrated with external ERP/WMS systems, not living inside app.
Architecture and Integrations
Typical structure for e-commerce with own delivery: client mobile app, courier app, dispatcher panel, integration with 1C/Moysklad/accounting system via API or message queue.
Merchandise catalog—not in mobile database. Sync with ERP via REST API or RabbitMQ/Kafka events on update. App caches catalog in Room/Core Data with TTL and invalidation on "assortment update" event.
Stock status—critical. Product unavailable shouldn't be orderable. Separate API endpoint for availability check on adding to cart and final order confirmation—double check mandatory.
Tariff Calculation with Product Parameters
For courier delivery, tariff depends not just on distance, but load characteristics:
- Weight—main parameter. Steps: up to 1 kg, 1-5 kg, 5-20 kg, over 20 kg
- Dimensions—"oversized" cargo (won't fit car) needs different transport
- Fragility—extra insurance, special packaging
- Temperature—food, medicines
Tariff matrix better stored server-side (don't hardcode in app). Cost request: POST /delivery/calculate with order parameters, response—list of available delivery types with price and estimated time.
Delivery Time Slots
Client chooses interval, not exact time. Slot system:
Slots generated N days ahead, each has order limit (capacity). When full—slot unavailable. Capacity depends on active courier count that period.
data class DeliverySlot(
val date: LocalDate,
val startTime: LocalTime,
val endTime: LocalTime,
val available: Boolean,
val remainingCapacity: Int
)
Selection screen—horizontal scroll by date, grid of slots below. Unavailable slots—gray, non-interactive. Popular pattern: first show "nearest available time" as recommendation.
Courier App for Goods Delivery
Significantly differs from taxi courier. Goods courier usually has multiple orders on one route, needs route optimization.
Route sheet—list of delivery points today, sorted by optimal route. Server calculates route optimization (Google Optimization API, OR-Tools or simple greedy for small routes) and passes courier sorted list.
Delivery confirmation—photo of recipient with goods or QR scan of order code. Signature on screen via UIBezierPath / Canvas API. Data saved as proof of delivery.
Partial refusal—client accepted 3 of 4 items. Courier marks refused positions, server creates return.
Client Tracking
Client gets push when courier starts moving. Map display—simplified tracking: courier marker + route + ETA. Need minute-level precision, not second-level like taxi—update once per minute sufficient.
SMS/WhatsApp notification with tracking link—for non-app users. Link leads to tracking webpage (PWA or simple HTML).
Returns and Claims
Return mechanics—separate flow: client initiates return, specifies reason, attaches photo. Server creates CRM/ERP ticket. Refund—via same payment gateway refund method.
Receipt and delivery document storage: archive to S3/MinIO with order metadata.
Timeline
MVP (one platform client + courier app, basic catalog, one delivery type): eight-fourteen weeks.
Full platform (iOS + Android, 1C integration, time slots, returns, dispatcher panel): four-eight months.
Cost determined after requirement analysis, integration scope and task decomposition.