Softech designed and developed Foodeli as a multi-channel operating platform for last-mile delivery. The system connected central administration, branch and dispatch tools, partner channels and a courier application through one request, status and settlement model. Requests from different sources were normalised before assignment, while operational logic considered location, availability, preparation time, priority, ETA and the option to batch compatible pickups and drop-offs. Execution data fed order history, reporting and settlement cycles. Project materials describe expansion from one city to eleven and a historical service and delivery standard of 40 minutes; this publication clearly marks those values as reported information and does not present unapproved cost or on-time percentages.
Business context and the situation before implementation
Foodeli operated at the intersection of marketplace demand, field logistics and local operations. Customer value depended not only on the ordering interface but on whether partners, dispatchers and couriers shared the same information and could react quickly to changes in preparation, location and fleet load.
- Requests could arrive directly from partners or external channels and needed one status model.
- Dispatch had to make time-sensitive decisions with incomplete courier availability and changing zone load.
- Couriers needed a current assignment list, addresses, action order and proof-of-completion flow.
- Partners and branches needed status visibility without constant phone coordination.
- Settlements had to connect request, route, compensation-rule and approved adjustment data.
- Expansion to additional cities required a repeatable model for roles, configuration and reporting.
Before state
Without a shared platform, every additional order source, branch or settlement model increased manual coordination. Dispatchers had to combine partner, preparation, courier and route information, while later settlement required reconstructing execution from several places.
- Different intake channels could describe similar requests in different ways.
- Assignment relied on current dispatcher knowledge and manual context assembly.
- Field statuses did not always create one history available to operations and finance.
- Launching a branch required repeating configuration and training local teams.
- Compensation models and adjustments increased the risk of manual correction.
- The lack of one operational picture made exceptions and delays harder to analyse.
Goals, success criteria and constraints
Discovery focused on the actual request lifecycle rather than screens. We mapped how a request was created, which data dispatch needed, courier decisions, field exceptions, proof of completion and settlement inputs. This separated rules shared across cities from local configuration.
Product goals
- Unify requests from multiple sources in one domain model.
- Connect central administration, branches, partners and couriers without duplicating process logic.
- Support dispatch with location, availability, priority and estimated-time data.
- Enable safe batching of compatible pickups and drop-offs with exception control.
- Record a complete execution history for customer support, reporting and settlements.
- Design a repeatable model for launching operations in additional cities.
- Preserve manual operator decision-making for cases that should not be resolved automatically.
Success criteria
- Every request has an explicit source, branch, status, partner and change history.
- Dispatch can see current load and accept, change or split an assignment.
- Couriers receive current jobs and return field statuses to the same data model.
- Partners can check execution state without reconstructing the process by phone.
- Settlement data comes from execution history and approved rules rather than a separate manual spreadsheet.
- Branch configuration applies shared policies while supporting local exceptions.
- An integration or asynchronous-process failure leaves an explainable status and operational trace.
Real-time decisions
Preparation, traffic, location and availability changed during execution, so plans had to be updated without losing history.
Multiple order sources
Partner channels and external integrations supplied data with different structures, quality and timing.
Local operating exceptions
Branches used one model but differed in zones, resources, hours and peak-response practices.
Batching versus service quality
An additional pickup could improve route utilisation only when it did not create unacceptable risk for other deliveries.
Complex settlement rules
Compensation could depend on job, distance, time, adjustments and payment cycle, requiring auditable inputs.
Connectivity and field work
The courier application had to communicate operation state under changing connectivity and reduce duplicate-action risk.
Analysis and product decisions
- Mapping order sources and their normalisation into a shared contract.
- Analysing dispatcher decisions from intake through reassignment and cancellation.
- Defining courier-application states including pickup, delivery and exceptions.
- Defining location data, ETA and job-compatibility conditions.
- Modelling partner and courier settlement rules and payment cycles.
- Separating central policies from branch configuration.
- Identifying manual-control points where automation could increase risk.
Solution architecture
The architecture was divided by operating responsibility. Partner channels submitted requests to a shared API, the domain layer maintained statuses and rules, planning mechanisms supported dispatch, the courier application handled field work, and execution data fed reporting and settlements. Central administration defined policies while branches managed current execution.
- 01Channel 01
Partners and order sources
Web panels, mobile channels and integrations supplying request data to the shared workflow.
ReactREST APIWebhooks - 02Channel 02
Branch and dispatch
Current requests, couriers, zones and priorities with manual intervention tools.
ReactTypeScriptMaps - 03Channel 03
Courier application
Assignments, addresses, action sequence, statuses, navigation and field confirmations.
React NativeMap SDKMobile notifications - 04Core 04
API and domain model
One source of rules for requests, deliveries, users, branches, statuses and permissions.
Node.jsNestJSTypeScript - 05Engine 05
Planning and asynchronous processes
ETA, job compatibility, event queues, integration retries and operational-data updates.
RedisQueuesRoute APIs - 06Data 06
Data, reporting and settlements
Execution history, branch configuration, settlement rules, reporting and change trace.
PostgreSQLObject storageMonitoring
Problems, decisions and implemented capabilities
Requests from different channels used different data and statuses.
Introduce one request contract before operational processing.
Normalisation of source, partner, addresses, timing, items and status.
Dispatch and couriers use one meaning of the request regardless of intake channel.
Manually combining location, preparation and availability slowed decisions.
Provide calculated context to dispatch while preserving manual control.
ETA, priority, availability, zones and assignment recommendation.
The operator can assess an option faster and explain or change the decision.
An additional pickup could improve a route or put other deliveries at risk.
Batch only requests meeting defined compatibility conditions.
Evaluation of distance, preparation, route capacity, windows and priority.
Batching becomes a controlled operating mechanism rather than automatic grouping of every nearby job.
Couriers needed current information without constant dispatcher contact.
Design the application around active and available assignments with explicit statuses.
Jobs, addresses, contact, sequence, status and proof of completion.
Field work produces structured events visible across the system.
Settlements required reconstructing data from separate sources.
Build financial inputs from approved execution events.
Rate rules, distance, job, adjustments and weekly or monthly cycles.
Operations and finance refer to the same request history.
Each new city could create a separate way of working and reporting.
Separate central policies from local configuration and current dispatch.
Branch model, roles, zones, parameters, reports and permissions.
Launching another location uses the existing model rather than a new application.
Technology decisions
| Technology | Role | Rationale | Trade-off |
|---|---|---|---|
| React + TypeScript | Administration, branch and partner panels | Shared components and typed contracts supported several operational tools. | Interactions still had to be designed separately for different roles and data density. |
| React Native | Courier application and partner mobile channel | A shared iOS and Android base with access to maps, location and notifications. | Background work, location and mobile operating-system behaviour required native testing. |
| Node.js + NestJS | API, domain rules and integrations | TypeScript across layers reduced contract drift and supported modular responsibility boundaries. | Modularity required discipline to keep business logic out of controllers and clients. |
| PostgreSQL | Requests, deliveries, branches, users and settlements | A relational model suited transactional states and consistency-sensitive relationships. | Operational reporting required indexes, aggregation and separation from transactional paths. |
| Redis + queues | Asynchronous processes, retries and short-lived data | Integrations and operating events should not block the main request flow. | Queues require idempotency, monitoring and explicit dead-event handling. |
| Mapping and route services | Geocoding, ETA, distance and navigation context | Mature mapping data accelerated location and planning capabilities. | Cost, limits and provider variability required caching, fallbacks and request control. |
Integrations and data flows
Partner and aggregator channels
Into FoodeliSubmitting requests into one operating model regardless of source.
Contract validation, source identifiers, idempotency and retry handling.
Geocoding, maps and route estimation
Bidirectional request and response flowAddresses, distance, ETA, route view and dispatcher decision context.
Address validation, result caching, limit control and missing-estimate communication.
Finance systems and exports
Out of FoodeliTransferring approved partner, courier and settlement-period data.
Export status, retry capability and settlement-period identifier preservation.
Notifications and communication
From system to usersInforming users about assignment, status changes, exceptions and required action.
Queues, retries, channel preferences and separation from the domain transaction.
AI, security and reliability
Roles and branch scope
Permissions separate central, local, partner and courier operations.
Status consistency
Execution-state changes pass through domain rules and preserve history for investigation.
Integration idempotency
Repeated external-channel messages should not create another request or duplicate operation.
Field-work resilience
The application communicates uncertain state and synchronises events to reduce duplicates under weak connectivity.
Process monitoring
Integrations, queues and critical status transitions require metrics, alerts and retry capability.
Settlement trace
Financial inputs reference approved execution, rule and period so the result can be explained.
Implementation, testing and release
- 1Phase 1 — operating model
Translate the local delivery process into shared product concepts.
- Request and delivery map
- Partner, dispatcher and courier roles
- Core statuses and exceptions
Result: The first workflow could operate in one city and produced data for further iteration.
- 2Phase 2 — channels and dispatch
Connect order sources with operational tools.
- Partner panels
- Branch dispatch view
- Shared request contract and history
Result: Requests from different channels entered one operating model.
- 3Phase 3 — courier application and location
Provide a current field-work flow and return statuses to operations.
- Active and available assignments
- Addresses, contact and navigation
- Statuses and proof of completion
Result: Courier and dispatch referred to the same execution state.
- 4Phase 4 — planning and exceptions
Support ETA, assignment and batching decisions without removing operator control.
- Job compatibility rules
- Route and load context
- Manual change and split tools
Result: Optimisation mechanisms became part of a controlled dispatch workflow.
- 5Phase 5 — settlements and branches
Connect execution data with finance and prepare a repeatable location model.
- Compensation rules and cycles
- Branch and central reports
- Role, zone and policy configuration
Result: The system supported daily work across roles and expansion into additional cities.
Status-rule testing
Testing allowed transitions, cancellations, reassignment and protection against duplicate operations.
Dispatch scenarios
Validating single and batched jobs, unavailable couriers, preparation changes and manual intervention.
Mobile field testing
Testing statuses, maps, notifications and synchronisation under changing connectivity.
Integration testing
Handling incomplete data, delayed messages, duplicates and temporary provider unavailability.
Incremental rollout
New features and branch configurations were introduced incrementally with status and exception observation.
What confirms the project description
The functional scope is based on preserved screens, the existing project record and process models contained in the repository materials. Screens confirm selected courier-application elements, while diagrams structure the architecture and workflow description without pretending to be infrastructure documentation. Expansion to eleven cities and the 40-minute standard are marked as historical reported information. Earlier percentages for delivery cost, on-time performance, automatic allocation and accounting time are not published because no baseline, period and approved analytics export were provided.
| Scope | Basis | Reference | Confirmation | Interpretation boundary |
|---|---|---|---|---|
| The courier application presents active assignments with addresses and execution state. | Preserved product screen | FO-01 — active courier assignments | Confirmed | The screen confirms the interface and information scope, not completed-delivery volume. |
| The application separates current and available courier work. | Preserved product screens | FO-02 — current and available assignments | Confirmed | The material does not document every application version or availability rule. |
| Partners, branches, couriers and administration use a shared domain layer. | Architecture model | FO-03 — Foodeli logical architecture | Confirmed in the product | The diagram simplifies topology and does not disclose confidential infrastructure configuration. |
| The workflow carries a request from intake through assignment and execution to confirmation and settlement. | Process model | FO-04 — request and delivery lifecycle | Confirmed in the product | The diagram shows the target model, not request volume distribution across states. |
| Dispatch combines priority, availability, ETA and batching with manual operator control. | Decision model | FO-05 — dispatch and planning logic | Confirmed in the product | The material confirms logic scope but does not publish algorithm parameters or outcomes for every delivery. |
| The branch model combines central policies, local operations and settlement cycles; project history reports expansion to eleven cities. | Operating model and project history | FO-06 — branches and settlements | Confirmed by the client | Eleven cities is historical reported information and has not been independently reconfirmed as the current operating footprint. |
How to read this information
- Preserved screens do not show the entire system or every product version.
- Diagrams describe logical responsibilities rather than confidential deployment topology.
- Eleven cities and 40 minutes are historical values reported in project materials.
- There is no basis for publishing earlier cost, OTD, allocation and accounting percentages.
- Integration provider names and current connection status should be reconfirmed before detailed publication.
- Business impact is described as an operating-capability change rather than an approved financial result.
Process change, decision consequences and lessons
| Area | Before | After | Business impact |
|---|---|---|---|
| Order sources | Requests from different channels required manual alignment. | Channels submit data into one request and status model. | Operations do not need a separate workflow for every source. |
| Dispatch | Decision-making required manually combining location, preparation and availability. | The operator receives shared ETA, priority, route and load context. | Exceptions are handled in one tool and leave a decision history. |
| Courier work | Updates and task sequence required additional coordination. | The application shows current and available assignments and records field statuses. | Courier and dispatch refer to the same execution state. |
| Order batching | Shared-route feasibility was assessed informally and depended on operator experience. | Compatibility uses location, timing, capacity and priority rules with manual control. | Optimisation becomes a repeatable process rather than only an individual decision. |
| Settlements | Operating and financial data were assembled after execution. | Approved request events feed settlement rules and periods. | A calculation can be traced to a specific request, rule and status. |
| City rollout | A new location could create a separate set of roles, configuration and reports. | A branch uses the shared model with local zones and parameters. | Another rollout builds on the existing architecture rather than a separate system. |
Recommendation rather than fully automatic assignment
- Alternative
- Full automation without operator approval
- Trade-off
- Dispatch still performs some work but retains control over exceptions and operating quality.
- Rationale
- Preparation, local conditions and unusual jobs may require knowledge unavailable to the model.
One domain model across channels
- Alternative
- Separate logic for partner, courier and branch
- Trade-off
- The core is more demanding to design, but a status change does not need multiple implementations.
- Rationale
- Operations require one meaning of the request regardless of interface.
Rule-controlled batching
- Alternative
- Batching every geographically close request
- Trade-off
- Not every potentially shorter route is used, but delay risk for other deliveries is reduced.
- Rationale
- Proximity does not account for preparation time, capacity, sequence and priority.
Shared policies with local branch configuration
- Alternative
- Identical configuration for every city
- Trade-off
- The system manages more parameters but does not force artificial operational uniformity.
- Rationale
- Zones, resources and demand vary locally while roles and the request model should remain shared.
Asynchronous integrations with retries
- Alternative
- Every integration in the main transaction
- Trade-off
- Queues and intermediate states are introduced, but an external-channel failure does not need to stop the entire operation.
- Rationale
- Order sources, maps and notifications have different availability and response times.
Key lessons learned
- A logistics system should begin with an explicit request, status and responsibility model rather than a map.
- An assignment algorithm is useful only when the operator understands its recommendation and can handle exceptions.
- Batching requires full route context; distance between points alone is insufficient.
- A courier application must communicate uncertain state, especially when an action may have been sent under weak connectivity.
- Settlements are significantly easier when financial inputs come from approved operating events.
- A multi-branch model should separate shared policies from local parameters before expansion.
- Historical KPIs should not be carried into a new publication without a source, period and explicit measurement definition.
Which organisations this model is relevant for
Last-mile delivery operators
Companies coordinating requests, couriers, partners, zones and settlements in one or more cities.
Q-commerce and delivery networks
Organisations receiving orders from multiple sources and requiring their own dispatch logic.
Platforms with field operations
Products where mobile, location, statuses and proof of completion form one workflow.
Companies expanding a branch model
Organisations needing central policies, local configuration and comparable reporting.
Businesses with custom settlements
Operations where financial outcome depends on job, distance, time, adjustments and settlement cycle.
Related expertise and services
Web app development
Dispatch panels, partner portals and operating systems built on a shared data model.
Mobile app development
Field applications with location, synchronisation, notifications and controlled workflow.
Operations workflow automation
Designing statuses, queues, rules, integrations and operator tools for control-sensitive processes.
React Native
A shared iOS and Android application base with access to location capabilities.
Node.js
API backends, domain logic, queues and integrations for operating systems.
Gizo Rental — rental application and workflow
A related example connecting location, availability, documents and field operations.
KILOGRAM — web, mobile and AI marketplace
An example of a multi-channel product with a central API, operations panel and asynchronous workflows.
Cost of a custom business system
An analysis of scope, risk and cost in custom operating-system development.
Planning a custom dispatch or last-mile operations system?
We can turn order sources, branches, couriers, location, planning, statuses and settlements into one controlled web and mobile product.
Key confirmed facts
The following statements summarise the confirmed product scope and contain no unapproved growth data.
- 1
Softech designed and developed Foodeli as an operating platform for last-mile delivery.
- 2
Foodeli connected central administration, branch tools, partner channels and a courier application.
- 3
The system normalised requests from different sources into one domain model.
- 4
Dispatch used location, availability, priority and ETA data while retaining manual control.
- 5
The courier application presented active and available assignments and recorded execution statuses.
- 6
The batching mechanism evaluated pickup and drop-off compatibility instead of grouping requests by distance alone.
- 7
Request data could feed reporting and settlement cycles for partners and couriers.
- 8
The branch model separated central policies from local dispatch and configuration.
- 9
Project materials report historical expansion from one city to eleven.
- 10
Project materials report a historical service and delivery standard of 40 minutes.
- 11
The eleven-city footprint and 40-minute standard are published as reported information rather than independently verified measurements.
- 12
The overview does not publish earlier delivery-cost, on-time or accounting-time percentages without an approved analytics source.
Visual evidence
The diagrams present confirmed product scope and workflows described in this material. They are not mock-ups or claims of undocumented outcomes.
FAQ
How did the system batch requests without losing control of delivery time?
The mechanism evaluated pickup and drop-off compatibility using location, preparation time, current route, courier availability and priority. Dispatchers retained manual decision-making for exceptional situations.
Did Foodeli support orders from multiple sources?
Yes. The architecture normalised partner and external-channel requests into one operating model so dispatch and the courier application used consistent statuses.
How were multiple branches handled?
Shared rules, roles and data models were managed centrally, while local teams retained control over current dispatch, fleet load and exceptions.
Which data could feed settlements?
Settlements could use execution data such as the request, distance, time, status, compensation rule and additional components approved within the process.
Are the published outcomes independently verified?
The expansion to eleven cities and the 40-minute standard come from project history and are marked as reported information. Earlier cost and on-time percentages are not published without an approved analytics source.
Can a similar system support other field operations?
Yes, but the domain model should be designed around the organisation’s own jobs, resources, assignment rules, proof of completion, settlements and exceptions.
