MatatuOs

MatatuOS is the digital operating layer for Kenya’s matatu sector, helping SACCOs manage trips, fleets, bookings, manifests, and visibility in real time.

Comment

About the project

Inspiration

MatatuOS was inspired by a simple observation: Kenya’s matatu industry moves millions of people every day, but many of the systems behind it still run on phone calls, WhatsApp groups, paper records, manual dispatch books, and people simply knowing how things work.

Most transport technology solutions start with passenger booking or digital payments. But after looking deeper into how SACCOs, stage managers, dispatchers, drivers, and conductors actually operate, I realized the bigger problem comes before booking.

The first layer is visibility.

SACCOs need to know which vehicles are active, which crew is assigned, which trips are running, how many passengers boarded, how cash and M-Pesa collections compare, and where operational gaps are happening. Without that visibility, payments, bookings, tracking, and analytics become difficult to trust.

MatatuOS is my attempt to build an operations-first transport operating system for SACCOs and fleet owners — not just another booking app.

What it does

MatatuOS helps SACCOs manage daily transport operations from one portal.

The current system focuses on:

  • Fleet and vehicle management
  • Staff and crew management
  • Route and stage management
  • Dispatch trip creation
  • Boarding and capacity tracking
  • Booking Lite and passenger check-in
  • Cash closeout and reconciliation
  • Vehicle availability
  • Staff shifts
  • Operations day closeout
  • Audit timelines
  • Tenant-based access control
  • Platform admin onboarding and pilot request management

The goal is to give SACCO admins, operations managers, dispatchers, fleet managers, and auditors a clearer view of what is happening across vehicles, crews, trips, routes, collections, and exceptions.

Instead of trying to immediately replace conductors, stage managers, or existing SACCO workflows, MatatuOS is designed around the principle:

Adopt before replace.

That means the system can support hybrid operations where a SACCO may still use cash, paper manifests, WhatsApp coordination, or existing GPS vendors while gradually moving toward digital operations.

Why this matters

The matatu sector is not just a transport problem. It is an operations, trust, coordination, compliance, and visibility problem.

If a SACCO cannot clearly answer questions like:

  • Which vehicles operated today?
  • Which trips were completed?
  • Which trips had low boarding?
  • Which crew was assigned?
  • Which cash closeouts are pending?
  • Which bookings were checked in?
  • Which vehicle was unavailable?
  • Which action was performed by which staff member?

then scaling digital transport becomes very difficult.

MatatuOS tries to solve this from the SACCO side first.

The long-term vision is to become a secure, multi-tenant mobility operating system for public transport operators in Kenya and eventually across Africa.

How I built it

I built MatatuOS as a multi-tenant web platform with strong tenant isolation between SACCOs. Each SACCO operates as its own tenant, meaning its vehicles, staff, trips, bookings, revenue records, audit events, and operational data are separated from other SACCOs.

The backend is structured around modules such as:

  • Authentication and authorization
  • Role-based permissions
  • Fleet management
  • Staff management
  • Route management
  • Dispatch operations
  • Boarding summaries
  • Booking Lite
  • Cash closeouts
  • Vehicle availability
  • Staff shifts
  • Audit timelines
  • Offline review and sync visibility
  • Platform onboarding

I also added a security-focused permission model so different roles only see and perform the actions they are allowed to. For example, an auditor, dispatcher, SACCO admin, fleet manager, or platform admin can have different levels of access.

The system also includes audit logging so important actions can be traced later. This is important because transport operations involve money, staff responsibility, passenger records, and compliance.

On the frontend, I built a SACCO portal where admins and operators can view operational dashboards, manage dispatch, inspect bookings, review closeouts, check staff shifts, monitor vehicle availability, and handle onboarding requests.

Challenges I faced

The biggest challenge was realizing that the technical system is not the hardest part.

The harder problem is designing for how SACCOs actually work.

Many SACCOs already have existing workflows. They may use WhatsApp, Excel, paper manifests, manual cash books, existing M-Pesa tills, or older software. If a new system forces them to abandon everything immediately, adoption becomes difficult.

So I had to rethink the product from:

“Here is a new system, replace your old one.”

to:

“Here is a system that can plug into your current workflow and help you improve step by step.”

Another challenge was access control. In a multi-tenant system, one SACCO should never access another SACCO’s staff, vehicles, trips, revenue, manifests, bookings, or analytics. I spent a lot of time hardening tenant isolation, permissions, audit visibility, and sensitive data exposure.

Offline and poor-network conditions were also important. Matatu operations happen on the road, at stages, and in areas where connectivity can be unreliable. That pushed the architecture toward offline-first thinking, review queues, conflict handling, and graceful degradation.

What I learned

I learned that building for local transport requires more than copying global mobility apps.

The matatu industry already has its own operating system: people, stage managers, conductors, dispatchers, route habits, informal trust, cash flows, WhatsApp groups, and manual reconciliation.

The opportunity is not to erase that system overnight.

The opportunity is to make it visible, safer, more accountable, and easier to manage.

I also learned that the product should start where the pain is strongest. For MatatuOS, that is not necessarily passenger booking first. It is operations visibility first.

Payments, booking, tracking, analytics, compliance, and AI can all come later — but they need a trusted operational foundation.

What is next

The next step is to validate MatatuOS with real SACCOs, stage operators, drivers, conductors, and fleet owners.

Planned next steps include:

  • Field interviews with SACCOs and operators
  • Pilot onboarding for a small number of vehicles
  • Conductor-first mobile workflow
  • Offline-first vehicle/tablet mode
  • Import/export support for Excel and PDF manifests
  • Better cash and M-Pesa reconciliation
  • Live trip visibility
  • More polished SACCO dashboard experience
  • Pilot request collection from the public website

The long-term goal is to build transport digital transformation infrastructure that works with the reality of African public transport instead of fighting against it.

Built With

  • audit-logging
  • csv/json-exports
  • firebase/sms-notifications-planned
  • flutter-planned-for-conductor/vehicle-mode
  • for
  • jwt-authentication
  • m-pesa-integration-planned
  • media
  • multi-tenant-saas-architecture
  • nestjs
  • next.js
  • object
  • offline-first-architecture
  • permission-based-access-control
  • planned
  • postgis
  • postgresql
  • rabbitmq
  • react
  • redis
  • rest-apis
  • role-based-access-control
  • storage
  • tailwind-css
  • typescript
  • websockets
Share this project:

Updates