TaxiMize

Where to find passengers? - Smart Hotspots

AI-powered passenger demand forecasting based on temporal and spatial patterns. The darker zones indicate higher probability of finding passengers at that hour of that day in each zone, helping drivers optimize their positioning for maximum efficiency.

"See our demand heatmaps that show when and where passengers are most likely to request rides"

Which rides to accept? - Intelligent Ride Prediction

ML-powered ride evaluation system that estimates the economic value of each ride before acceptance. Get instant scoring from 1-5 stars to make informed decisions about which rides to accept.

"Get help choosing which are the rides that are worth accepting"
Our Ride Score (1-5 stars) is based on: fare per minute, drop-off zone quality and trip time

When to work? - Shift Starting Recommendation

AI-powered recommendations on optimal shift timing to maximize profitability. Get instant visual feedback on whether it's the right time to start driving based on demand patterns and historical data.

"Avoid Slow unprofitable periods and maximize your earnings by starting your shift at the best possible time"

Note: This feature currently uses hardcoded hours as it was not part of the initial MVP - planned for future development.

Check your statistics: Analytics Dashboard

Comprehensive statistics tracking your working vs idle time and detailed earnings analytics. View your performance metrics on weekly or monthly basis to optimize your driving strategy.

Keep your progress: Persistent State Management

Seamless app experience with full state persistence. Exit and return to the app without losing progress - counters, timers, and current page state are perfectly maintained across sessions.

Notice: Watch how page reloads maintain exact state - timers continue running and current page stays unchanged!

Customizable Preferences

Personalize your experience with:

• Dark/Light Mode - Choose your preferred theme
• Multi-language Support - Currently available in English and German
• Safety Notifications - Configure automatic break reminders (every 3 hours for driver safety)

Database Schema Foundation

• Key Business Constraints

  • One Active Shift: Only one shift per driver can have shift_end = NULL
  • One Active Ride: Only one ride per shift can have end_time = NULL
  • Signal Validation: State transitions must follow logical sequence
  • Soft Deletes: Shifts and rides are never physically deleted

• Driver Signals

  6 possible signals drivers can send to the system:

  • start shift - Begin working session
  • pause shift - Take a break
  • continue shift - Resume from break
  • stop shift - End working session
  • start ride - Begin passenger trip
  • end ride - Complete passenger trip

Signal State Machine - Driver State Transitions

Driver Shift States

The current state of a driver's shift is determined by the last signal they sent:

none

No active shift

available

Shift started, no ride, not paused (last signal: start, continue or end-ride)

on_ride

Shift started, ride active (determined by Ride entry with end_time = NULL)

paused

Shift started, no ride, paused (last signal: pause)

Changing a Driver State: All driver state changes must pass through the SignalValidation gateway, which ensures only valid transitions occur. This prevents impossible states like starting multiple shifts or pausing when not working.

Valid Signals:

null → start
start → pause / stop
pause → continue / stop
continue → pause / stop
stop → none

Example Signal Flow:

1. Driver sends 'start' signal → Validation checks (null→start) ✓ → Shift created
2. Driver sends 'pause' signal → Validation checks (start→pause) ✓ → Pause created
3. Driver sends 'continue' signal → Validation checks (pause→continue) ✓ → Pause ends
4. Driver sends 'pause' signal → Validation checks (continue→pause) ✓ → New pause
5. Driver sends 'stop' signal → Validation checks (pause→stop) ✓ → Shift ends

Ride Eligibility System

Rides have their own validation workflow separate from signals. A ride can only start if all three conditions are met: active shift, not paused, and no current ride.

Detailed Check Flow

1. 1

   Check Active Shift

   Has Active Shift? → If NO: Deny (No Active Shift)

2. 2

   Check Pause Status

   Last Signal = Pause? → If YES: Deny (Shift is Paused)

3. 3

   Check Active Ride

   Has Active Ride? → If YES: Deny (Ride Already Active)

Implications of Starting a Ride

We consider a ride active if an entry is created but the end time is null. Starting a ride has important implications:

Signal Block

No signal can be received until a ride is finished

Ride Limit

No other ride can be started (only one ride per active shift)

Signal-to-Database Action Mapping

Every signal and action triggers specific database operations:

1. 1

   CREATE-UPDATE Pattern

   Shifts and rides follow a CREATE-UPDATE pattern: We first create an entry when starting, then update it with end times and totals when stopping.

   Active Status: We consider a shift/ride to be active if it has a start time but no end time (End Time = NULL)

2. 2

   Retroactive Creation

   Pauses uniquely use retroactive creation: we only create the pause entry once it finishes.

   How it works: We can achieve this thanks to the timestamps of the signals received (stored in the signals table)

• Shift Signals

  'start' signal

  CREATE new shift entry (Null End Time)

  'stop' signal

  UPDATE shift with end time & totals
  And DELETE all signals from that shift

• Pause Signals (Retroactive)

  'pause' signal

  No immediate DB action (timestamp stored)

  'continue' signal

  CREATE pause entry retroactively

• Ride Signals

  Start Ride

  CREATE new ride entry (Null End Time)

  End Ride

  UPDATE ride with earnings & duration

Timeline Example:

Automatic Cleanup on Login

The system automatically manages stale data when drivers log in, ensuring abandoned shifts and rides don't accumulate in the database. This cleanup runs asynchronously without blocking the login process.

• Cleanup Thresholds:

  • Rides: 4+ hours of inactivity → Closed with 0 earnings
  • Shifts: 1+ day of inactivity → Ended (with rides) or Deleted (empty)

• Important Notes:

  • User-specific: Only affects logged-in driver's data
  • Non-blocking: Runs async, doesn't delay login

Featured Capability: Persistent State Management

One of the powerful features enabled by this architecture is persistent state management. The signal-based system allows the frontend to restart and restore the user exactly where they left off by tracking their last action and timestamp.

State Persistence in Action

The system maintains driver state across page reloads, app crashes, or network disconnections:

Notice: Watch how page reloads maintain exact state - timers continue running and current page stays unchanged!