Carsharing Mobile App Development

Carsharing Mobile App Development

User taps "unlock" on the map — command goes to the car's CAN-bus via IoT block, door opens in 2–4 seconds. If nothing happens after 30 seconds, he taps again. Door opens twice. This is why vehicle control commands require idempotency keys and confirmation via callback, not fire-and-forget.

Telematics and Vehicle Control

The heart of a carsharing platform is a telematics block in the car (Teltonika FMB140, Queclink GV620, Neomatica ADM700 or similar) that connects to the server via GPRS/LTE and receives commands: open/close doors, permit/forbid engine start, activate alarm. The mobile app itself doesn't talk to the car — everything goes through the server.

Command flow:

1. App sends command to API (POST /cars/{id}/commands) with idempotency-key
2. Server writes command to queue (RabbitMQ or Kafka)
3. Worker sends command to telematics block via TCP/UDP
4. Block confirms execution
5. Server sends push notification to app with result

If step 4 doesn't happen within 30 seconds — server returns error, app shows specific status. Not "something went wrong," but "vehicle didn't respond to command — possibly no network in this area."

Map and Vehicle Search

Fleet display on map — clustering markers at low zoom. Google Maps SDK and MapKit both support this natively, but with 500+ cars online you need server-side clustering: server returns clusters with centroids and counts, client draws aggregated markers. At zoom > 14 switch to individual icons with battery/fuel level color indicators.

"Find nearest available car" — request with user geolocation and radius. PostGIS on backend (ST_DWithin) + coordinate index. Response — list with distance and walking route via Google Maps Directions (mode WALKING).

Onboarding and Verification

Carsharing requires driver's license and passport verification. Standard path — integration with liveness + document recognition services:

• Smile Identity or Onfido for international projects
• Sufteh, GetID or ECRN (via Gosuslugi / GIS MVD) for Russian market

Technical implementation: native camera with document placement guidance (frame overlay), photo upload via multipart/form-data, polling verification status via WebSocket. Don't store document photos on device beyond upload session.

Rental and Payment

Rental session — state machine: available → reserved → active → completed. Each transition is atomic on the server. Mobile client displays current status via WebSocket subscription or long-polling with ETag.

Payment — Stripe (international) or YooKassa/CloudPayments (Russia). Important nuance: amount hold (payment_intent with requires_capture status) at rental start, actual charge after completion with recalculation by actual time. Stripe SDK for iOS and Android provides ready Payment Sheet that handles 3DS, SCA, card saving.

Vehicle Condition Check

Before rental starts user photographs scratches and damage. Protection for both user and operator. Implement via CameraX with multiple captures, upload to cloud (S3/GCS) with geotag (EXIF GPS data) and timestamp. After rental completion — same.

Automatic damage detection via ML model (YOLOv8 fine-tuned on car damage) — optional feature implemented via Core ML (iOS) or TensorFlow Lite (Android). Reduces inspection team load but requires quality dataset.

Architecture and Stack

Development Stages

1. Audit of telematics infrastructure — what blocks are installed, what protocol, is there API
2. State machine architecture for rental on server + API contract with mobile client
3. Design — map, search, onboarding, rental session
4. Development — MVP includes: map with fleet, booking, vehicle unlock, payment, rental completion
5. Verification — KYC provider integration, testing edge cases (expired license, blurry photo)
6. Publication — App Store (Transport category) + Google Play

Timeline: MVP — 3–4 months, full platform with analytics, corporate cabinet and advanced telematics — 6–9 months. Cost calculated individually after requirements audit.