How a Cuban Developer Built a Ride-Hailing App on a 2G Budget

When fuel shortages crippled transportation in Cuba, one developer turned adversity into innovation by building a lightweight ride-hailing app from the ground up. Instead of starting from scratch, he repurposed Organic Maps, stripped it of unnecessary features, and customized its map data to create a system capable of handling over 20,000 real taxi rides—all on devices with limited resources and unreliable connectivity.

The app’s architecture was designed to overcome severe constraints: phones with only 1GB of RAM, intermittent 2G signals, and no reliable cloud infrastructure. By leveraging OpenStreetMap data and optimizing every component, the developer delivered a functional ride-hailing solution where traditional apps would fail.

A Minimalist Architecture Built for Low-End Hardware

The system consists of three core components, each tailored for Cuba’s infrastructure challenges:

• Passenger app (58MB): Enables users to request rides, search addresses offline, and track nearby drivers in real time—all without requiring an internet connection after the initial setup.

• Driver app (62MB): Allows drivers to receive ride requests, accept assignments, and share their live location with passengers.

• Lightweight Python/Django backend: Matches passengers with the nearest available drivers using real road distances calculated by OSRM, avoiding the need for Nominatim, an online geocoding service.

The entire system operates offline, except for the initial ride-matching process, ensuring functionality even during connectivity outages.

Trimming 100MB Off the Map to Fit Budget Phones

Organic Maps, while feature-rich, was never intended for a taxi dispatch system. Its default map files for Cuba weighed over 160MB—far too large for low-end Android devices. The developer needed a leaner solution without sacrificing essential functionality.

Beyond Code Removal: Rebuilding the Map Itself

Most developers would start by removing unused code from the app. While that helped, the real breakthrough came from generating custom map files (*.mwm format) optimized specifically for ride-hailing.

The original Organic Maps map files included:

• Translations for over 50 languages, most irrelevant in Cuba.
• Unnamed polygons (empty lots, unnamed fields) from OpenStreetMap.
• Full metadata for every point of interest, even those unnecessary for taxi services.

By rebuilding the map pipeline, the developer made targeted reductions:

• Filtered out unnamed polygons: Removed all geographic features without a name tag, such as empty parking lots or unlabelled fields.
• Stripped down language support: Retained only Spanish and English, cutting metadata size by roughly 80%.
• Embedded a custom search index: Built a compressed search index directly into the .mwm file, eliminating the need for Nominatim and enabling instant offline address lookups.

The result was a 25MB map file—less than half the size of Organic Maps’ default Cuba map—and crucial for devices with limited storage.

Code Optimization: Keeping Only What Matters

With the map size under control, the developer turned to the app’s codebase. Unnecessary features were removed:

| Feature removed | Reason | |------------------|--------| | Track recording | Passengers don’t need route history for taxi rides | | Multi-threaded rendering | Reduced RAM usage; real-time panning isn’t critical for riders | | Cloud bookmark sync | No cloud infrastructure in Cuba; local sync suffices | | World map tiles | Only Cuba was needed |

What remained was repurposed for taxi-specific functions. For example, the BookmarkManager component became the "Favorite Places" feature, allowing passengers to save home and work addresses for one-tap ride requests.

The final APK sizes reflected this efficiency:

• Passenger app: 58MB
• Driver app: 62MB

Boot time on old Android devices dropped from 8 seconds to under 3 seconds.

Solving Offline Search Without a Server

In most ride-hailing apps, typing an address like "Calle 23 esq. L, Vedado" sends a query to Nominatim, a geocoding service that requires an internet connection. In Cuba, where connectivity is unreliable, this approach was impossible.

The solution? Embed the search index directly into the map file.

How the Custom Index Powers Offline Lookups

Organic Maps includes a robust offline search system (SearchEngine, Geocoder, Processor, Ranker), but it relies on standard metadata. The developer replaced this with a custom index tailored for Cuban addresses.

The index contains:

• Street names, normalized for common misspellings and abbreviations.
• Intersection names (e.g., "23 y L").
• Named landmarks (e.g., "Parque Central", "Capitolio").
• Precise coordinates for every entry.

When a passenger types a query, the app:

1. Tokenizes the input locally.
2. Searches the embedded index using a custom fuzzy matching algorithm.
3. Returns results in under 2 seconds—without ever touching the internet.

This approach eliminated the need for Nominatim, servers, or external dependencies, making the app fully functional in offline mode.

Real-Time Tracking Without Backend Bloat

Passengers need to see nearby drivers on the map, while drivers must track their own location and pickup points. Organic Maps includes lightweight marker systems (UserMark, Bookmark, SearchMarkPoint) designed for real-time updates without redrawing the entire map.

The developer extended this system with custom markers:

• Driver app: Uses a new TaxiDriverMark class (inheriting from UserMark) to display the driver’s live position, updated every 3 seconds via UDP.

• Passenger app: Receives a list of nearby driver coordinates and statuses from the backend, then renders them as markers on the map.

This method ensures smooth performance on low-end devices while keeping the backend lightweight—no heavy WebSocket connections or frequent API calls required.

A Model for Resilient Tech in Constrained Environments

This project demonstrates how open-source tools and careful optimization can deliver functional technology where commercial solutions fall short. By rebuilding map data, trimming code, and embedding offline functionality, the developer created a ride-hailing app that thrived in Cuba’s challenging conditions.

The lessons extend beyond Cuba: in regions with limited infrastructure, repurposing existing tools and prioritizing offline-first design can unlock solutions that would otherwise be impossible.

As connectivity improves and hardware evolves, the foundation laid here could scale—proving that even under constraints, innovation isn’t just possible; it’s inevitable.