Week 29 Day 01 Discovery & Analysis

Last-Mile Delivery App

A comprehensive solution to handle the most complex, volatile, and financially demanding phase of the supply chain.

Project Vision

Empowering drivers and closing the gap between planning and execution in the final mile.

1. What is "Last-Mile Delivery"?

Last-mile delivery (also known as the final mile) is the final step in the delivery process, where a product moves from a warehouse, fulfillment center, transport hub, or local distribution depot to the customer's doorstep or a designated pickup point. It is the most complex, volatile, and financially demanding phase of the supply chain.

Because the last mile directly represents the physical point of contact between a business and the end consumer (which could be an individual or another business), it has an outsized impact on brand perception and customer loyalty.

Key Examples:

On-Demand Food Delivery: Delivering prepared hot meals from local restaurants directly to customers within minutes (e.g., restaurant courier apps like Uber Eats or Azyan).
E-Grocery & Perishables: Delivering fresh produce and groceries from supermarket chains or specialized dark stores directly to homes, which often requires temperature-sensitive logistics.
Courier, Express, & Parcel (CEP) Services: Standard residential shipping of e-commerce packages, parcels, and mail (e.g., DHL, FedEx, Swiss Post, or La Poste).
Wholesale & Industrial Distribution (B2B): Transporting commercial goods, construction materials, or wholesale food and beverages directly to retail stores, construction sites, or business clients under strict operational schedules.
Click-and-Collect (BOPIS) & Parcel Lockers: Transporting aggregated online orders to automated parcel lockers or smart pickup stations at transit hubs, retail plazas, or offices, allowing customers to retrieve their packages at their convenience.

Top 10 Issues in Last-Mile Delivery

Last-mile delivery is notoriously difficult because it is highly exposed to real-world friction.

1. High Operational Costs

The last mile represents approximately 53% of total shipping expenses. Driven by fuel, driver wages, low drop density, and manual handoffs.

2. Failed and Delayed Deliveries

Redelivering a package a second or third time can multiply delivery costs by 2.5 to 3 times the original budget.

3. Low Delivery Density

Final delivery vans typically complete only 70 to 90 residential stops per shift, destroying economies of scale.

4. Route Inefficiencies

Suboptimal planning can lead to unnecessary mileage, longer transit times, and vehicles running with half-empty trunks.

5. Extreme Time Waste per Stop

Up to 88% of stop time is wasted on finding parking, walking to entrances, navigating elevators, or clearing gates.

6. Urban Congestion

Heavy traffic, road closures, and a lack of dedicated commercial vehicle parking slots severely disrupt planned schedules.

7. Inflexible Customer Expectations

Consumers expect precise time slots, same-day shipping, or instant tracking updates, placing pressure on operations.

8. Labor Scarcity & Turnover

Logistics networks face chronic driver shortages and extremely high turnover rates (35% to 45%), driving up costs.

9. Static Plan Decay

Static routes generated the night before degrade immediately due to delays, weather, or cancellations.

10. Siloed Systems

When OMS, WMS, and TMS do not communicate, lost inventory and manual status-reconciliation errors compound rapidly.

Top 10 Essential Functionalities

Empowering drivers on the road with a production-grade last-mile delivery mobile application.

1 Persistent Location Tracking

Continuous, reliable GPS tracking that remains active even when the app is minimized or screen locked, feeding live coordinates to maps.

2 Battery-Conscious Motion

Automatically pause high-power GPS polling when stationary and reactivate upon movement to conserve battery using on-device sensors.

3 Real-Time Route Optimization

Step-by-step guidance, allowing drivers to accept mid-shift re-optimizations, reorder stops on-the-fly, and switch transit modes.

4 Off-Route Detection

Triggers visual or audio alerts when a driver deviates from the designated sequence, prompting immediate routing correction.

5 ePOD Signature Capture

Built-in signature canvas and GPS-stamped photo upload interface with delivery notes to resolve customer disputes instantly.

6 AR Overlays & Barcode

Rapid camera-based scanning using AR screen overlays to immediately highlight search items or sequence numbers on multiple packages.

7 On-Device ID Verification

Secure scanning of IDs or passports locally on the device for high-value or age-restricted deliveries, protecting privacy.

8 Offline-First Data Storage

Local embedded database allowing drivers to log data without internet, syncing automatically in background once connected.

9 Phone & SMS Masking

In-app communication via temporary proxy phone numbers, keeping personal contact numbers secure and on-platform.

10 Geofenced Arrival Alerts

Automatically triggering local push notifications and alerting the customer when driver enters a geofence radius of the delivery location.

Week 29 Day 02 Minimalistic Scope & Flow

Minimalistic Delivery Scope

Streamlining core package listing, delivery execution, key actors, and sequence of operations.

Minimal Scope Overview

To build a minimalistic last-mile delivery application focused strictly on retrieving a daily delivery list, providing a route map, and marking deliveries as completed.

1. Essential Features for the Minimalistic App

Out of the 10 production-grade functionalities, only four are strictly necessary to implement your minimal scope:

1 Real-Time Route Optimization & Dynamic Navigation

Required to display the route map, order of stops, and provide turn-by-turn guidance for the delivery agent on the road.

2 Electronic Proof of Delivery (ePOD) Signature Capture

Necessary to mark deliveries as "completed" by allowing the agent to capture a customer signature or take a delivery photo.

3 Offline-First Data Storage & Async Synchronization

Crucial for ensuring that if the agent enters a signal dead zone (basements, elevators, rural areas), they can still access their daily delivery list and mark orders completed offline.

4 Persistent Background Location Tracking

Essential for maintaining the agent's active position on the route map even when the app is minimized, ensuring navigation is seamless and real-time ETAs stay accurate.

2. Key Actors Involved

Three primary entities interact across the delivery lifecycle.

Delivery Agent (Driver)

The primary mobile app user who views the delivery list, follows the route map, executes physical deliveries, and captures proof of completion.

Dispatcher / Back-Office

The logistics operator or centralized system that compiles customer orders, optimizes daily route sequences, assigns shipments to drivers, and monitors execution.

Customer

The end receiver of the package who physically accepts the delivery and provides the required verification (e.g., a signature) to confirm receipt.

3. Sequence of Operations to Complete a Delivery

End-to-end workflow between Dispatcher, Delivery Agent, and Customer.

Delivery Workflow Diagram

Sequence of Operations to Complete a Delivery Flow Diagram

Detailed Step-by-Step Flow:

1
Route Generation and Assignment:
The Dispatcher uses the back-office logistics system to generate the optimized sequence of stops for the day and assigns this list to the Delivery Agent.
2
Daily List Retrieval:
The Delivery Agent opens the mobile app, which fetches the assigned delivery list. The app uses Offline-First Data Storage to save the addresses, customer details, and sequence locally on the device.
3
Route Mapping and Navigation:
The Delivery Agent selects the first stop. The app utilizes Dynamic Navigation to display the route map and provide real-time turn-by-turn routing.
4
Transit Tracking:
While the agent is driving, the app utilizes Background Location Tracking to feed coordinate updates back to the Back-Office System, keeping dispatchers informed of the live progress and ETA.
5
Arrival and Handoff:
The Delivery Agent arrives at the designated address and physically hands the package to the Customer.
6
Proof of Delivery:
The Customer signs on the app's signature canvas (or the driver takes a package photo) to verify successful receipt of the shipment.
7
Marking Completion (Local):
The Delivery Agent taps "Complete Delivery" in the app. The app instantly saves the ePOD data and updates the status to "Completed" in its local database.
8
Asynchronous Synchronization:
The app's Async Synchronization queue pushes the completion status and signature back to the Dispatcher / Back-Office System. If the agent is in a cell dead zone, the queue securely holds the data locally and syncs it automatically the moment internet connectivity returns.

Week 29 Day 03 Data Architecture

Database Models & JSON Schemas

Translating the core actors and essential functionalities into a practical database and transmission architecture.

1. Grounded Relational Models

Designed to support a robust local database (SQLite/Hive) and remote API backend. Includes Agent, Customer, Route, Stop, Delivery, ePOD, LocationTelemetry, and SyncQueue.

Agent (Driver)

agent_id (UUID, PK)
name (VARCHAR)
phone (VARCHAR)
vehicle_type (VARCHAR)
status (VARCHAR)

Customer

customer_id (UUID, PK)
name, phone (VARCHAR)
address_line_1, address_line_2 (VARCHAR)
city, postal_code (VARCHAR)
lat, lng (DECIMAL)

Route

route_id (UUID, PK)
agent_id (UUID, FK)
date (DATE)
status (VARCHAR)

Stop

stop_id (UUID, PK)
route_id (UUID, FK)
sequence_number (INTEGER)
eta (TIMESTAMP)
status (VARCHAR)
lat, lng (DECIMAL)

Delivery (Order)

delivery_id (UUID, PK)
stop_id, customer_id, epod_id (UUID, FK)
package_details (TEXT)
status (VARCHAR)

ePOD (Proof of Delivery)

epod_id (UUID, PK)
delivery_id (UUID, FK)
signature_data, photo_data (TEXT Base64)
completed_at (TIMESTAMP)
capture_lat, capture_lng (DECIMAL)

LocationTelemetry

telemetry_id (BIGINT, PK)
agent_id (UUID, FK)
lat, lng (DECIMAL)
timestamp (TIMESTAMP)
motion_state (VARCHAR)

SyncQueue

sync_id (UUID, PK)
action_type (VARCHAR)
payload (TEXT JSON)
status (VARCHAR)
retry_count (INTEGER)

2. Entity-Relationship (ER) Mapping

A complete structural diagram showing primary and foreign key dependencies, illustrating how routes transition into sequenced stops, and how deliveries bind to customers and ePOD records.

*Note: The SyncQueue table runs as an auxiliary process locally on the driver's device to serialize transactions before sending them back via REST or WebSockets.

3. RFC-Compliant JSON Schemas

Three complete draft-07 schemas ready for copy-pasting into your mobile validation engine or back-office API.

3.1 Daily Route List Payload

Handles the ingestion of optimized daily stops when the driver starts a shift.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "DailyRouteList",
  "type": "object",
  "required": ["route_id", "agent_id", "date", "status", "stops"],
  "properties": {
    "route_id": { "type": "string", "format": "uuid" },
    "agent_id": { "type": "string", "format": "uuid" },
    "date": { "type": "string", "format": "date" },
    "status": { "type": "string", "enum": ["PENDING", "EN_ROUTE", "COMPLETED"] },
    "stops": {
      "type": "array",
      "minItems": 1,
      "items": {
        "type": "object",
        "required": ["stop_id", "sequence_number", "eta", "status", "lat", "lng", "deliveries"],
        "properties": {
          "stop_id": { "type": "string", "format": "uuid" },
          "sequence_number": { "type": "integer", "minimum": 1 },
          "eta": { "type": "string", "format": "date-time" },
          "status": { "type": "string", "enum": ["PENDING", "ARRIVED", "COMPLETED", "FAILED"] },
          "lat": { "type": "number", "minimum": -90, "maximum": 90 },
          "lng": { "type": "number", "minimum": -180, "maximum": 180 },
          "deliveries": {
            "type": "array",
            "minItems": 1,
            "items": {
              "type": "object",
              "required": ["delivery_id", "customer", "package_details", "status"],
              "properties": {
                "delivery_id": { "type": "string", "format": "uuid" },
                "status": { "type": "string", "enum": ["PENDING", "DELIVERED", "FAILED"] },
                "package_details": { "type": "string" },
                "customer": {
                  "type": "object",
                  "required": ["customer_id", "name", "phone", "address"],
                  "properties": {
                    "customer_id": { "type": "string", "format": "uuid" },
                    "name": { "type": "string" },
                    "phone": { "type": "string" },
                    "address": {
                      "type": "object",
                      "required": ["address_line_1", "city", "postal_code", "lat", "lng"],
                      "properties": {
                        "address_line_1": { "type": "string" },
                        "address_line_2": { "type": "string" },
                        "city": { "type": "string" },
                        "postal_code": { "type": "string" },
                        "lat": { "type": "number", "minimum": -90, "maximum": 90 },
                        "lng": { "type": "number", "minimum": -180, "maximum": 180 }
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

3.2 ePOD Upload Payload

Manages base64 signature/photo captures and offline-first transactional synchronization.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "ePODUploadPayload",
  "type": "object",
  "required": ["epod_id", "delivery_id", "signature_data", "completed_at", "capture_coordinates"],
  "properties": {
    "epod_id": { "type": "string", "format": "uuid" },
    "delivery_id": { "type": "string", "format": "uuid" },
    "signature_data": { "type": "string" },
    "photo_data": { "type": "string" },
    "completed_at": { "type": "string", "format": "date-time" },
    "capture_coordinates": {
      "type": "object",
      "required": ["lat", "lng"],
      "properties": {
        "lat": { "type": "number", "minimum": -90, "maximum": 90 },
        "lng": { "type": "number", "minimum": -180, "maximum": 180 }
      }
    },
    "notes": { "type": "string", "maxLength": 500 }
  }
}

3.3 Telemetry Payload

Governs background location tracking points, including battery-saving motion status flags.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "AgentTelemetryPayload",
  "type": "object",
  "required": ["agent_id", "coordinates", "timestamp", "motion_state"],
  "properties": {
    "agent_id": { "type": "string", "format": "uuid" },
    "coordinates": {
      "type": "object",
      "required": ["lat", "lng"],
      "properties": {
        "lat": { "type": "number", "minimum": -90, "maximum": 90 },
        "lng": { "type": "number", "minimum": -180, "maximum": 180 },
        "speed": { "type": "number", "minimum": 0 }
      }
    },
    "timestamp": { "type": "string", "format": "date-time" },
    "motion_state": {
      "type": "string",
      "enum": ["MOVING", "STATIONARY"]
    }
  }
}

Week 29 Day 04 API Specification

API Design & Mock Server

Industry-standard REST API specification mapping core functionalities to production-ready endpoints.

Key API Groups Defined

This specification directly translates the three core actors (Delivery Agent, Dispatcher, and Customer) and four essential functionalities into an industry-standard, production-ready REST API design.

Route & Stop Management

/routes

Contains endpoints for the driver to fetch their daily optimized sequence, perform real-time re-optimizations, and log arrival timestamps. Supports offline cache-building on-device.

ePOD Submission

/deliveries

Enables the driver to commit signature captures, upload delivery confirmation photos, and handle failed delivery attempts with reason codes (e.g., `CUSTOMER_UNAVAILABLE`).

Location Telemetry

/telemetry

High-frequency endpoint for continuous background location updates. Uses throttling constraints (50m, 5s) to conserve driver battery.

Offline Queue Sync

/sync

Transactional batch sync endpoint designed to flush events logged locally while offline. Resolves data state conflicts using timestamps.

Public Customer Tracking

/tracking

Generates secure, token-based public tracking pages returning active driver coordinates, planned route path, and predictive machine-learning-driven ETAs.

Exposed Mock Endpoints & Mechanics

GET /api/v1/routes/{agent_id}

Daily Routes & Stops

Purpose: Fetches the structured list of optimized daily sequences, stops, customers, and parcel metadata.

Offline-First Support: The JSON payload is optimized for direct ingestion by mobile local database engines (such as Hive or SQLite).

POST /api/v1/stops/{stop_id}/arrive

Geofenced Stop Arrival

Purpose: Logs the agent's arrival coordinates and triggers a timestamp in the database. Acts as a trigger for localized notifications.

POST /api/v1/deliveries/{delivery_id}/complete

Electronic Proof of Delivery (ePOD)

Purpose: Accepts base64 encoded signatures and photographic confirmations. Automatically updates the database and flags parent stops as COMPLETED.

POST /api/v1/telemetry

Background Geolocation Telemetry

Purpose: Receives high-frequency GPS coordinate pings (lat, lng, speed, heading, battery, motion status).

Battery Management: Accepts throttled updates (changes >50m or 5s) to prevent device battery drain.

POST /api/v1/sync

Asynchronous Offline Sync

Purpose: Accepts a chronological array of batch transactions that occurred offline and applies them atomically to the database.

GET /api/v1/tracking/{route_id}

Public Dynamic Tracking

Purpose: Returns dynamic tracking state combining driver vehicle metrics, last known location, and predictive ETAs.

Live Python Mock Server

A Python FastAPI mock server has been built to implement the exact endpoints from the API contract, integrating a persistent local SQLite database (`last_mile_mock.db`). It comes pre-populated with realistic dummy data allowing you to test the mobile application directly with a live backend immediately.

Download last-mile-mock-server.py

How to Run the Mock Server

Ensure you have fastapi and uvicorn installed, then execute the script:

pip install fastapi uvicorn
python3 last-mile-mock-server.py

Upon launching, the mock server will:

Initialize the SQLite database last_mile_mock.db locally if it does not exist.
Create all relational tables (including routes, stops, deliveries, epods, and telemetry).
Seed the tables with a sample active route (R301) for Agent A101 (Marcus Vance) and 3 sequential stops.

The console will output structured logging in real-time as coordinates are posted, matching the exact telemetry schemas.

Week 29 Day 05 Mobile UI Blueprint

Mobile App Screens

Complete, high-fidelity UI specifications mapping core functionalities to our minimalistic brand palette.

Color Mapping & Theme

Deep Forest

#000F08

Active Pine

#136F63

Amber Gold

#E0CA3C

Crimson Orange

#F34213

Interactive Indigo

#3E2F5B

LTE 100% 08:30 AM

MOBO LOG

DELIVER

Server Base Endpoint:

https://api.logistics.mycompany.com

Agent ID / Username:

marcus.vance_101

Security Password:

*****************

Remember Endpoint Settings

- OR -

System Status: Connection Verified (Ping: 14ms)

Screen 1: Auth & API Config

The entryway for the Delivery Agent to authenticate and configure the client-side app. Establishes a session with the back-office server or custom REST API. Includes a hidden server configuration drawer for environment mappings.

State & Validation Logic

Default State: Reads `last_mile_mock.db` local cache to check for previously stored API URLs and usernames.
Validation: Endpoint must be valid HTTPS. Agent ID cannot be empty.
Transition: "LOG IN" triggers GET `/api/v1/routes/{agent_id}`. Falls back to offline cached credentials if disconnected.

LTE 100% 08:35 AM

MANIFEST

Marcus (A101)

ACTIVE TRACKING

ROUTE: R301 (Manhattan-Brooklyn)

Stops Completed 64% (2 of 3)

⚠️ 3 Pending Actions (Offline Sync)

Next Stop

ST-002: Harold Finch 09:12 AM

21 E State St, Columbus, OH

1 Package | COD: None

QUEUED MANIFEST LIST

✓

ST-001: John Doe

ST-002: Harold Finch (IN-TRANSIT)

ST-003: Root Kelly (QUEUED)

Screen 2: Route Manifest Dashboard

The central hub for the Delivery Agent. Presents a progress metrics bar of completed stops and lists the remaining stops for the day sequenced by optimal travel path. Hosts the global sync status badge for offline actions.

State & Validation Logic

Offline State: Status badge turns Amber (`#E0CA3C`). Stops fetched directly from local SQLite database.
Sync Action: Tapping the amber queue badge routes directly to the Offline Sync Manager.
Navigation: Pressing "START NAV" shifts context into live dynamic navigation mode.

LTE 100% 08:38 AM

BACK

STOP ST-002 DETAILS

Harold Finch

21 E State St, Columbus, OH 43215

"Leave in parcel box if no answer."

Parcel Verification

Item ID: P-908234-A

⚠️ UNVERIFIED

Offline Map Preview

S2 Spatial Cell Index: 4/156

STATIC LEAFLET PREVIEW

Screen 3: Stop Details & Barcode

Displays operational metadata of a selected stop including customer notes and address geocodes. Requires the driver to scan the parcel barcode locally to verify the items are correct before handoff.

State & Validation Logic

Enforcement: Navigation is disabled (50% opacity) until barcode status shifts to VERIFIED.
Fallback: Manual text field entry available if the camera scan fails.
Cancel Action: Tapping Cancel prompts for an Odoo reason code (e.g. `CUSTOMER_UNAVAILABLE`).

LTE 100% 08:45 AM

⏸️ PAUSE

Harold Finch

Remaining Leg

1.2 Miles

Est. 4 Min

ETA 09:12 AM

OFF-ROUTE DEVIATION

App detected you are off-route by 85m.

Screen 4: Dynamic Live Nav

Immersive mapping interface demonstrating persistent background location tracking and real-time dynamic route optimization. Features a custom blue-dot marker utilizing gyro-rotation.

State & Validation Logic

Deviation Detection: If driver strays >50 meters from the path geometry, an audio cue and the dynamic Crimson warning drawer appear.
Battery Save: If stationary >5 minutes, GPS enters passive-polling state to conserve battery power.

Week 29 Day 06 Infrastructure & Mobile Code

System Infrastructure & Mobile App Code Execution

Full execution of backend services, serverless functions, RESTful APIs, and Flutter mobile client application codebase.

100%

Infrastructure Setup

Cloud DB & Telemetry Store

100%

Backend Functions & APIs

REST Routes & Webhooks

100%

Mobile Code Base

Flutter Clean Architecture

4/4

Core Features Built

GPS, Route, ePOD, Offline

1. Basic Infrastructure & Backend Functions Execution

Provisioning datastores, serverless cloud functions, and REST API endpoints

Execution commenced with bootstrapping the full system infrastructure. The backend services were architected to support high-frequency telemetry ingestion from driver smartphones, route optimization calculations, and proof-of-delivery storage.

Telemetry & Database Services

Live Location Store: High-throughput Firestore collection logging 5-second location ticks for active drivers.
Jobs & Route Repository: Relational PostgreSQL schema managing active delivery assignments, waypoints, and customer stops.
ePOD Storage Bucket: Cloud Blob Storage for encrypted proof-of-delivery signatures and delivery photo captures.

Cloud Functions & API Services

POST /api/v1/jobs/sync: Syncs assigned delivery manifests with driver mobile app.
POST /api/v1/telemetry/location: Ingests batch location packets and triggers off-route detection.
POST /api/v1/jobs/epod: Verifies customer signature, geofence status, and updates delivery state.

2. Mobile Application Code Development

Constructing the Flutter client app according to Day 5 UI Blueprints

Following infrastructure deployment, full code creation for the mobile application was executed. The application was constructed using Flutter, implementing a clean modular architecture separated into core infrastructure, data repositories, business logic (BLoC), and responsive UI views.

Module A

Background Geolocation & Navigation

Integrated native location hooks with persistent foreground service execution, active heading calculation using device gyro, and dynamic Mapbox map rendering.

Module B

ePOD Signature Canvas

Built high-precision touch signature capture canvas, camera photo capture interface with EXIF GPS tagging, and real-time validation logic.

Module C

Offline Sync Engine

Implemented SQLite transactional queue for offline delivery updates, auto-retrying background sync worker, and push notification handlers.

Code Execution & Build Pipeline Summary

1

Backend & Cloud Infrastructure Initialized

API Gateway routes, Firebase/PostgreSQL schemas, and Serverless cloud functions deployed successfully.

Completed

2

Mobile Client App Scaffolding & State Management

Flutter app project structure created with BLoC state architecture, dependency injection, and theme configurations.

Completed

3

End-to-End API Integration & Mobile Verification

Connected mobile screens to mock telemetry engine, verified location streaming, ePOD capture, and offline queueing.

Completed

Week 29 Day 07 Final Release & Source Code

Mobile Application Completed & Deployed

The mobile application build was finalized, thoroughly validated, and published to the official GitLab repository.

Official Repository Release

Explore the Complete Codebase on GitLab

The full mobile application code, backend API functions, mock telemetry server, and architectural documentation have been finalized and committed to GitLab.

Repository:

https://gitlab.com/52weekchallenges-group/mylastmileapp

Open GitLab Repository Public Git Repository • Active Project

1. Mobile Application Completion Summary

Final quality audit, core feature verification, and app build completion

On Day 7, the mobile application development cycle reached 100% completion. All primary modules—including real-time background location tracking, turn-by-turn routing visuals, dynamic off-route recalculation, electronic proof of delivery (ePOD), and offline transaction synchronization—were rigorously tested and approved.

Validated Mobile Workflows

Driver Authentication: Secure JWT session handling and manifest retrieval.
Active Navigation: Smooth gyro-assisted marker tracking with low battery impact.
Off-Route Warning: Instant pop-up alert & re-optimization when 50m deviation detected.
ePOD Signature & Photo: Touch signature rendering, geo-stamping, and instant upload.

Build Release Artifacts

Android App Bundle (.aab / .apk): Production release build optimized with ProGuard obfuscation.
iOS Runner Archive: Xcode project configurations with location entitlement keys.
Mock Telemetry Engine: Standalone Python test script for simulating delivery agents.

2. GitLab Repository Architecture

The repository is organized following clean architecture patterns to separate UI, domain logic, data sources, and cloud backend scripts.

// Repository Tree Structure (https://gitlab.com/52weekchallenges-group/mylastmileapp)

mylastmileapp/
├── lib/                        # Flutter Mobile Application Source
│   ├── main.dart               # App entrypoint & theme setup
│   ├── core/                   # Shared utilities, API client, & theme constants
│   ├── features/
│   │   ├── auth/               # Driver login & token storage
│   │   ├── navigation/         # Mapbox map view, turn-by-turn guidance, deviation drawer
│   │   ├── epod/               # Signature canvas, photo capture, & EXIF parser
│   │   └── sync/               # SQLite local queue & background sync worker
├── backend/                    # Cloud Infrastructure & Backend Functions
│   ├── functions/              # Node.js / Serverless API routes
│   └── mock-server/            # Python telemetry & GPS mock generator
├── docs/                       # Architecture diagrams, API specs, & UI blueprints
└── README.md                   # Project setup guide & documentation

3. Week 29 Project Completion Checklist

Day 1: Requirements & Problem Statement

Day 2: Domain Analysis & Sequence Flows

Day 3: API Specification & Contracts

Day 4: Data Models & ER Schemas

Day 5: Mobile UI Blueprint & Wireframes

Day 6: Code Creation & Mobile App Dev

Day 7: Mobile App Completion & GitLab Upload 100% Published