Case study: Atlas app for truck drivers

Crowdsourced navigation app that enables truck drivers to help each other by updating real-time road info.

Kotlin
Java
ReactJS
BeeGo

Solving a problem for truckers

Truckers drive blind. Navigation apps are built for cars, not 18-wheelers. They don't account for weigh stations, low bridges, or parking spaces large enough for a rig.

Bad weather and road construction aren't just inconveniences for a truck driver—they're safety hazards. When you're hauling 40 tons, you can't just make a U-turn if the road is closed up ahead.

We needed to build a trip planning companion that understands the specific reality of trucking: unreliable connectivity, specific points of interest, and the need for community-sourced updates.

Project goals

The core requirement: enable a community of drivers to update real-time road status. To make this work at scale, we had three constraints:

UX for tired eyes
Drivers use this app after eight hours on the road. Buttons need to be big. Information needs to be instant. If a bridge is closed, they need to know 50 miles ago, not 500 feet ago.

$50 Android phones
We couldn't assume flagship hardware. The app had to fly on the $50 Android devices that are common in the fleet. Performance wasn't a nice-to-have; it was a hard constraint.

Offline first
Signal dies on the highway. In vast regions of Russia and Kazakhstan, mobile coverage is a myth. The app had to function completely offline, syncing data only when a connection survived for more than a few seconds.

Client feedback

"They were willing to help every step of the way and remained as transparent as possible throughout the process. I knew exactly what they were doing in each sprint. They delivered within budget and on schedule, and brilliantly solved any challenges that popped up."

Alexander Ponomarev

CEO of Atlas project

Our solution

Atlas is Waze for trucks. It crowdsources traffic, weather, and road conditions specifically for drivers hauling heavy loads.

We built a full-stack service designed for resilience. The backend handles the heavy lifting, allowing the mobile clients to remain lightweight and responsive even on low-end hardware.

Key features:

Offline-first architecture: Full mapping and routing capabilities without a signal.
Community syncing: Changes (like a closed road) sync to all drivers as soon as a connection is available.
Admin moderation: A web panel for verifying user-submitted data points before they go live.

Main

Routes

Filter

Engineering challenges

Clustering 200,000 points without crashing the browser

We imported 200,000 OpenStreetMap geopoints into our database. Rendering Moscow alone required 40MB of data. On a high-end iPhone on Wi-Fi, that's heavy. On a $50 Android phone on EDGE? It's impossible.

The map became unusable.

Standard client-side clustering libraries (like Mapbox Supercluster) work well for normal loads, but they choked on this dataset. NodeJS was too slow for the heavy math required to cluster this density in real-time.

We moved the problem to where we had power: the server. We wrote a custom clustering component in Go.

Porting kdbush for speed

We needed a spatial index that was fast and memory-efficient. Existing Go libraries (geo.go, tile38, rtreego) were either too generic (N-dimensional) or too memory-hungry.

We found kdbush, a JavaScript library for 2D spatial indexing, and ported it to Go. By stripping away non-2D logic, we built Gocluster—a hyper-specialized library for geospatial point clustering.

The result: We benchmarked Gocluster against Mapbox Supercluster on the same dataset (1M points, 21 zoom levels). The performance gain was massive.

Choosing the right map infrastructure

Better data than Google
Google Maps is great, but its coverage in rural Russia and Kazakhstan is spotty. Yandex Maps is better there, but lacks a native Android component.

We chose Mapbox. It gave us:

Granular offline support (essential for our use case)
Better styling control for our specific UI needs
A viable path to adding turn-by-turn navigation later

Solving auth when email doesn't exist

The reality of the user base
30% of our drivers don't have an email address. Asking them to "check your inbox to reset password" is a UX dead end.

We needed phone-based auth (WhatsApp style). Enter your number, get a code, you're in.

Twilio failed us
We tried Twilio first. It's the standard choice. But in Russia, due to telecom regulations and filtering, only 25% of our OTP messages were actually delivered.

We scrapped Twilio and found a local SMS aggregator with direct carrier agreements. The catch? No API. We wrote a spec, they implemented it for us, and we integrated it. Delivery rates hit 99%.

Infrastructure & Data Residency

Russian law requires user data to physically reside on servers within the country. This ruled out our standard AWS playbooks.

We didn't want to get locked into a specific Russian cloud provider (many are unreliable). The solution was Docker. By containerizing the entire architecture, we made it infrastructure-agnostic.

We developed on DigitalOcean, then migrated the containers to specialized VScale servers in St. Petersburg in 15 minutes. Best of both worlds: modern dev workflow, compliant production environment.

Documentation as a product

We treat API documentation as part of the codebase. We moved away from proprietary tools like Stoplight and standardized on OpenAPI (Swagger).

This allows third-party developers to build on top of Atlas without asking us how the endpoints work.