Most software answers questions about something that has already been recorded. Mobility software often asks a harder question: what is happening now?
Where is a driver relative to a pickup? Is the rider’s request still active? Did an assignment reach both devices? Did the ride change state while one device was offline? Is the information in an operations tool consistent with what each participant sees?
Building Naka requires us to consider questions like these. Relevant areas include real-time marketplace infrastructure, location-aware systems, ride matching, payments, notifications, identity, reliability, observability, security, and support tooling. These are areas of work, not a claim that every system is already complete.
Shared state in a changing world
A ride is not one record. It is a sequence of state changes observed by different systems and people under imperfect network conditions.
The platform needs a clear model of allowed transitions and an authoritative view of current state. Devices need enough local context to remain understandable through temporary connection problems. Repeated messages must not create repeated actions. Delayed events must not quietly overwrite newer truth.
These are familiar distributed-systems concerns, but mobility makes their consequences immediate and visible. The model has to be technically correct and legible to the rider, driver, and people responsible for operating the platform.
Location is evidence, not certainty
Location data varies in accuracy and freshness. It can be affected by the device, surroundings, permissions, battery settings, network conditions, and the way measurements are sampled.
A useful location system therefore needs more than coordinates. It should carry time, accuracy, and context. The product should avoid presenting more certainty than the underlying signal supports. Marketplace decisions need to account for movement and staleness rather than treating every point as equally reliable.
The objective is not to collect the largest possible location history. It is to use appropriate data for defined purposes while controlling access and retention.
Dispatch is a decision system
Dispatch connects demand with available supply. Distance matters, but it is not the only useful input. Road layout, estimated movement, ride state, driver availability, and marketplace conditions may all affect which opportunities are practical.
Whatever logic is used, the surrounding system needs safeguards. It should know which version of a decision was made, prevent conflicting assignments, record relevant outcomes, and provide enough visibility to investigate unexpected behaviour.
At Naka’s current stage, we are designing these foundations rather than publishing claims about completed scale or performance.
Payment state has to remain clear
A payment attempt can be confirmed, delayed, declined, or disputed. A ride-hailing product has to represent that state clearly and avoid presenting uncertainty as a completed result.
Driver subscriptions add another relationship: payment status and platform-access status need to remain consistent. Naka has not published the implementation or final commercial rules for this part of the product.
Reliability includes the people operating the system
Observability is useful when it helps someone understand impact and act. Logs, metrics, traces, audits, alerts, and operational tools should connect technical symptoms to product state without exposing sensitive information unnecessarily.
Runbooks and support tooling are part of the architecture because software alone will not resolve every real-world exception. A good system should make unusual states visible, preserve the information needed to investigate them, and give authorised people safe ways to respond.
Urban mobility is physical, local, and time-sensitive. Building for it means accepting that reality and designing software whose state remains clear even when the world around it is not. The Naka platform overview connects these engineering concerns to the rider, driver, and marketplace flow.