KibRide.
A ride-hailing platform for North Cyprus — passengers, drivers, live tracking, upfront fares and scheduling, all driven by one real-time state model.
- Industry
- Ride-hailing
- Country
- North Cyprus
- Our role
- Real-time backend, driver & passenger UX, operations dashboard
- Team
- Three — lead + two developers
- Duration
- Concept to production
- Status
- Live in North Cyprus
- Hard part
- One state model for three different audiences
Three audiences, one truth about where the car is
Ride-hailing in a smaller market has to earn trust immediately: the passenger needs to know where the driver is and what they will pay, the driver needs a flow that keeps them driving instead of reading menus, and the operator needs to see the whole board.
Three interfaces reading three versions of the truth is how these products fail. So the trip — its location, fare and status — was modelled once and everything else was made a view of it.
Four decisions that shaped it.
The trip is the record
Location, fare, status and driver assignment are one authoritative record. Passenger app, driver app and dispatch dashboard all read the same thing, so nothing needs reconciling later.
Upfront fare, no surprises
Fares are quoted before the trip is accepted and locked to the record, which removes the single biggest cause of disputes in a new market.
A driver flow with almost no interface
The driver screen is one decision at a time, thumb-reachable, readable in daylight, and safe to use in a moving vehicle.
Degrades instead of dying
Weak mobile coverage is normal, not exceptional: position updates buffer and reconcile, and the interface says what it knows rather than freezing.
How it is put together.
- DATA
- One canonical trip record; driver, vehicle and passenger as related entities with an auditable status history.
- REAL TIME
- Streaming position and status updates with buffering and reconciliation over unreliable mobile networks.
- PRICING
- Fare quoted, versioned and locked to the trip before acceptance.
- INTERFACE
- Separate passenger, driver and dispatch surfaces on one shared contract; mobile-first throughout.
- OPERATIONS
- Live dispatch view with vehicle verification, trip history and intervention on any active ride.
- OBSERVABILITY
- Every status transition logged, so any completed or cancelled trip can be replayed.
Stack & disciplines
- Real-time state
- Backend architecture
- Mobile-first UI
- Operations tooling
- UX/UI
A live market platform, not a prototype
- Passengers, drivers and dispatch operate from one consistent picture of every ride.
- Fare disputes are answerable from the record instead of from memory.
- New cities or vehicle classes are configuration on the existing model.
- The same three people who built it still run and extend it.
Trip volume figures are the client's to share; available on request.
Other builds.
AutomateOnline
A platform for automating recurring online work: scheduling, background processing, retries and a full audit trail, with an interface an operator can actually run it from.
Hard part: Unattended work that reports honestly
View case study
Mituteed
A public-facing Estonian platform built on a schema designed to stay legible as the product grows, with the interface drawn against the real data rather than a mockup.
Hard part: Staying fast while the catalogue keeps growing
View case study
Säästupark
A consumer-facing platform where third-party systems are held at arm's length from the core, so an outage upstream degrades one feature instead of the product.
Hard part: Surviving other people's downtime
View case studyHave a build like this one?
Send the brief and get a candid assessment of the hard parts — including a clear no, with a reason, if it is not right for us.