Citylink

Riders in Romania were juggling one app per mode: a taxi dispatcher on the phone, a ride-hailing app for peak hours, a separate card and account for car-sharing, and yet another for the bikes at the corner dock. Operators had the mirrored problem — four fleets, four sets of software, no shared view of demand.

One account, one payment method, four modes. The hard part was not the app; it was making dispatch and billing behave the same way whether the vehicle was a taxi with a meter, a partner driver, an unattended car unlocked over IoT, or a shared bike released from a dock.

Bike-sharing added its own constraints: per-minute billing with a free grace period, dock and geofence enforcement, battery and lock telemetry, and rebalancing reports for the operations crew moving bikes overnight.

Dispatch and billing were pushed off the request path from the start, onto Kafka and Amazon SQS, so a burst of Friday-night demand queued rather than collapsed.

AWS from day one, with WebSocket channels carrying live vehicle position and ride state to riders, drivers and the operations room. Backend across Laravel and C# .NET services, native iOS in Swift and Objective-C.

A twenty-person team across backend, mobile and QA was hired and run in parallel with the build — the organisation and the product were designed together.

PHP 7 / Laravel and C# .NET services, Node.js edges, MySQL and PostgreSQL, Redis and Memcached, Kafka and Amazon SQS for asynchronous dispatch and billing, WebSockets for live state, Stripe for payments, IoT for the car-sharing fleet.