How Boda and Matatu Saccos Use Software (And Who Builds It)

If you have ever ridden a matatu in Nairobi, you have interacted with the sacco system without knowing it. Every matatu belongs to a sacco (Savings and Credit Cooperative). The sacco owns the route license. Individual vehicle owners register their matatus with the sacco. Drivers operate the vehicles and remit daily payments to the sacco and to the vehicle owner.

The money flow looks like this: a matatu on the Rongai route collects fares all day. At the end of the day, the driver gives KES 3,000 to the vehicle owner (the "daily target") and KES 200 to KES 500 to the sacco as a management fee. The sacco uses these fees for route management, insurance, savings, and administrative costs.

Boda-boda saccos work similarly but on a smaller scale. Riders in a boda group contribute daily or weekly to a pool that covers insurance, savings, and emergency funds. The group chairman tracks contributions, often in a notebook.

The paper trail looks like this: the sacco manager has a ledger. Each page lists the vehicles registered, the expected daily remittance, and columns for each day of the month. When a driver sends M-Pesa, the manager checks the M-Pesa confirmation message, writes the amount in the ledger, and moves to the next driver. For a sacco with 50 vehicles, this daily reconciliation takes 1 to 2 hours. For a sacco with 200 vehicles, it takes all morning.

That manual process is where software steps in.

Sacco managers do not ask for "a fleet management platform with real-time analytics and predictive maintenance." They ask for: "I need to know who has paid today and who has not." Start there.

Daily payment tracking. This is the number one need. Drivers send daily remittances via M-Pesa to the sacco's paybill or till number. The system automatically matches each payment to a driver (by phone number or account reference), records the amount, and shows the manager a dashboard: green for paid, red for unpaid. No more cross-referencing M-Pesa statements against a paper ledger.

Member and vehicle registry. A database of drivers, vehicle owners, vehicles (registration number, insurance status, inspection dates), and the relationships between them. Driver X operates vehicle KCJ 123A owned by member Y. When insurance expires, the system sends a reminder.

Financial reports. Monthly and yearly summaries: total collections, individual driver payment history, outstanding arrears, sacco expenses. These reports are needed for AGMs (Annual General Meetings), SASRA (the sacco regulatory authority) compliance, and internal management.

SMS notifications. Automated messages to drivers: daily reminders ("Your daily contribution of KES 500 is due"), payment confirmations ("KES 500 received. Ref: QKL7XX"), and arrears alerts ("You have KES 2,000 in unpaid contributions for this week").

GPS tracking (for larger saccos). Some matatu saccos want to track vehicle locations. This requires GPS hardware in each vehicle and a mapping interface. It is a more complex feature that larger, well-funded saccos request. Smaller saccos and boda groups do not need this initially.

Automating M-Pesa payment collection is the feature that sells sacco software. Here is how it works technically.

Option 1: Paybill with account numbers. The sacco gets an M-Pesa paybill number. Each driver has a unique account number (often their vehicle registration number). When a driver sends KES 500 to the paybill with account number "KCJ123A," the system receives a C2B (Customer to Business) callback from Safaricom with the amount, the sender's phone number, and the account reference. Your system matches this to the driver's record and marks them as paid for the day.

Option 2: STK Push. The system sends an M-Pesa STK Push to each driver's phone at a set time (say, 6 PM when routes are closing). The driver sees the M-Pesa prompt, enters their PIN, and the payment is collected automatically. This is more proactive than waiting for drivers to remember to pay, but some drivers resist it because they feel pressured.

Option 3: Till number. Similar to paybill but without account numbers. Payments are matched by phone number. This works when each driver has a registered phone number in the system. Simpler setup, but breaks when a driver pays from a different number.

Handling edge cases:

• Partial payments. Driver sends KES 300 instead of KES 500. The system records it and shows KES 200 outstanding for the day.
• Late payments. Driver pays Tuesday's contribution on Wednesday. The system allocates the payment to the correct day based on the sacco's rules.
• Payments from wrong numbers. Driver uses a different phone. The payment arrives but cannot be auto-matched. The admin manually attributes it.
• Duplicate payments. Driver accidentally pays twice. The system flags the duplicate. The admin decides whether to credit it to the next day or refund via B2C.

Getting these edge cases right is what separates a demo from a production system. The happy path (driver pays correct amount from registered number) is easy. The exceptions are where your system proves its value.

Sacco software in Kenya is built by a mix of established companies, small development shops, and freelance developers. Here is the landscape.

Established platforms. Companies like Digital Matatus, Swvl (before they pivoted), and several enterprise software firms sell packaged solutions to large saccos. These are full platforms with fleet management, GPS tracking, payment processing, and compliance reporting. They charge monthly fees and require sales processes.

Small dev shops. Two-to-five-person development teams that build custom sacco management systems. They work with individual saccos, build tailored solutions, and provide ongoing support. This is the most common model because each sacco has slightly different rules and requirements.

Freelance developers. Individual developers who build and maintain sacco systems. This is a viable freelance niche because: the technical complexity is moderate (web app + M-Pesa + SMS), the clients are local (you can meet them in person), the contracts include ongoing maintenance (recurring revenue), and the domain knowledge creates a moat (a sacco will not switch developers easily once the system has their data).

The opportunity for a developer learning the African Stack is clear. Thousands of saccos need digital systems. Most cannot afford enterprise platforms. A developer who can build a clean, reliable payment tracking system with M-Pesa integration and basic reporting has a real client base. The first client is the hardest. After that, referrals from sacco to sacco drive growth.

The technical requirements are straightforward. No exotic frameworks needed.

Frontend: A responsive web app that works on both desktop (for the sacco manager in the office) and mobile (for checking payment status on the go). React, Vue, or server-rendered HTML with Tailwind CSS. The admin dashboard needs tables (driver payment status), charts (monthly collection trends), and forms (add driver, add vehicle). Keep it simple and fast-loading.

Backend: Node.js with Express or Python with Django/Flask. REST API serving the frontend and handling M-Pesa webhooks. Authentication for managers and optionally for drivers (phone number + OTP).

Database: PostgreSQL. Transport saccos handle real money, so you need ACID-compliant transactions. Your schema includes: sacco details, members (drivers and owners), vehicles, daily_payments, transactions, and notifications. Use proper database transactions when recording payments.

M-Pesa integration: Daraja API for C2B (receiving paybill payments), STK Push (proactive collection), and B2C (refunds or payouts to members). The callback endpoints are the critical piece. They must be reliable, fast, and idempotent.

SMS: Africa's Talking or Twilio for sending daily reminders and payment confirmations. Budget about KES 1 per SMS. For a sacco with 100 drivers receiving a daily reminder and a payment confirmation, that is about KES 6,000 per month in SMS costs.

Hosting: A VPS on Hetzner, DigitalOcean, or AWS. The app is lightweight. A 2 GB RAM instance handles a sacco with hundreds of drivers. Total hosting cost: KES 500 to KES 2,000 per month.

Sacco managers do not hang out on LinkedIn or Twitter. You need to find them where they are.

Visit sacco offices. Matatu saccos have physical offices, usually near their route terminals. Walk in. Ask to speak to the manager or chairman. Explain what you build. Bring a printout or a phone demo. Sacco managers are businesspeople who respond to tangible demonstrations, not pitch decks.

Attend sacco AGMs. Annual General Meetings are where sacco leaders gather. Getting invited to present your system to the members during an AGM is the fastest way to close a deal. Ask a sacco contact to introduce you.

Start with boda groups. Boda-boda groups are smaller, have simpler needs, and make decisions faster. Build a system for a boda group of 20 riders. Get it working well. Then use that as a reference when approaching larger matatu saccos. "I built the system for the Umoja boda group. Here is what it does. They collect KES X per month. Here are the reports."

Pricing. For a basic payment tracking system: KES 50,000 to KES 150,000 for development plus KES 5,000 to KES 15,000 per month for hosting and maintenance. For a system with GPS tracking and advanced reporting: KES 200,000 to KES 500,000 plus higher monthly fees. These prices are reasonable for saccos managing hundreds of vehicles and millions of shillings in monthly collections.

If building transport and fintech systems interests you, our Full-Stack Software and AI Engineering course (KES 120,000) teaches the full-stack and payment integration skills you need. The M-Pesa module alone gives you enough to start building sacco systems.