A ride-hailing app can make transportation look simple. Enter a destination, request a ride, and wait for a car to arrive. Underneath that short interaction is a live coordination problem: people, vehicles, roads, locations, payments, time, and uncertainty all moving at once.
We are building Naka because we believe that coordination can be designed more carefully—for the rider requesting transportation and the driver choosing to provide it.
Start with both sides
Ride-hailing is a two-sided marketplace, but “two-sided” should mean more than having two apps. Every marketplace decision changes the experience on both sides.
A matching decision can affect rider waiting time and the usefulness of an opportunity for a driver. A pricing decision can affect the clarity of a rider’s purchase and the economics of a driver’s work. A support process can determine whether either person feels heard when the normal flow breaks down.
It is tempting to optimise these pieces separately. The harder and more useful work is to understand their connection.
Naka is being built with that connection in mind. The rider experience, driver platform, marketplace systems, and operations are not separate projects that happen to share a brand. They are parts of one product.
Make the relationship understandable
For drivers, we are exploring subscription access in daily, weekly, and monthly periods. The principle behind this work is clarity: a driver should be able to understand what they pay to access the platform and the period that access covers.
There are important details still to define and validate. A subscription does not remove the realities of demand, operating costs, location, time, or individual choice. It does not guarantee rides or earnings. Prices and complete commercial terms will only be shared once they are ready.
But the structure matters. We think the basis of a driver’s relationship with a platform should be visible, considered, and possible to explain in plain language.
Treat reliability as product work
Mobility software operates in the physical world. A network delay, an inaccurate location, a missed state transition, or unclear information is not an abstract software defect. It can leave a person waiting on a road, or a driver deciding what to do without enough context.
That is why the less visible systems matter: dispatch, location, notifications, identity, payments, observability, support tooling, and operational processes. They determine whether the interface can keep its promises.
Naka is early. We are actively building the product rather than presenting a finished service. That gives us an obligation to separate intent from fact, publish details when they are verified, and resist filling unknowns with confident marketing language.
The standard we want to hold
We want Naka to be understandable. Riders should understand the state of a request. Drivers should understand the basis of access. Teams operating the platform should understand what the system is doing and where it needs attention.
That does not make urban transportation simple. It makes complexity something the product team is responsible for managing—not something people should have to absorb without explanation.
This journal will document that work: the product choices, engineering questions, marketplace principles, and company decisions involved in building Naka. The platform overview and driver model describe how those ideas are taking shape today. We will write about what we know, be direct about what is still being developed, and update the record as the platform takes shape.