01 / Case study
rentiQ
liveProperty management SaaS
Our own product. A property management platform for Kenyan landlords and agents, built around automatic M-Pesa rent reconciliation.
The problem
Kenya is a nation of renters, and the business of managing those rentals still runs on spreadsheets, notebooks, and WhatsApp threads. Rent arrives as a stream of M-Pesa messages: partial payments, a relative paying from a different number, no account reference. Matching that money to tenants at month-end takes days, and it is where revenue quietly leaks. Without a live ledger, arrears surface weeks after they start. Tenants dispute balances and nobody can produce a clean statement on demand. Meanwhile KRA is pushing on rental income and eTIMS, the Data Protection Act sets rules for tenant records, and a growing share of Kenyan property is owned from abroad by people managing it through relatives and phone calls with no verifiable view of the money.
What we built
We built rentiQ as a system of record for rental money and everything attached to it. Payments arrive either automatically through the client's own M-Pesa Paybill or by hand from a caretaker with a cash box, and both go through one allocation engine that applies them to the right invoices in the right order, flags anything ambiguous for a two-click resolution, and leaves an audit trail. Around that core sit the operations of a rental business: buildings and units, lease lifecycles, maintenance tickets, staff roles and permissions, a tenant portal, and a reporting suite written for the Kenyan market first.
- Automatic M-Pesa reconciliation, C2B and STK push, into the client's own Paybill
- Manual payment recording for cash, bank, and offline M-Pesa
- Smart allocation with a suspense queue for anything ambiguous
- Instant SMS and email receipts
- Buildings, units, tenants, and the full lease lifecycle
- Aged arrears, rent roll, owner statements, and a KRA rental income summary
- Maintenance tickets with photos, assignment, and cost tracking
- Role-based access down to per-building caretaker scoping
How the money engine works
Reconciliation is the product. The decisions below are the ones that decide whether a landlord trusts the arrears figure, and they are the same kind of decisions we make on client work, which is why this section exists at all.
One allocation engine, whatever the money came in as
A Daraja callback and a caretaker typing in a cash payment land in the same place. Both are recorded as a payment against a tenant, then applied to outstanding invoices in a defined order, so the arrears figure has one derivation rather than one per collection method. Building two paths here is the decision that eventually gives a client two different answers to the same question.
The messy payments are the product
Exact payments are easy. rentiQ is built for the rest: partials, overpayments, a wrong or missing account reference, a relative paying from their own number, and Safaricom retrying a callback we have already seen. Nothing is guessed. Anything the engine cannot place with confidence goes to a suspense queue for a human to resolve in two clicks, and every allocation can be traced and reversed cleanly.
The client's Paybill, never ours
Rent flows into each client's own M-Pesa Paybill. We are never in the payment path and we never hold anybody's money, which removes an entire class of trust, float, and licensing problem. Each client's Daraja credentials are stored encrypted and scoped to them, and a guided wizard turns Safaricom's go-live process into an assisted setup rather than a week of forms.
History imported, so the reports mean something on day one
Most tools in this market start a client at zero, which makes every report meaningless for the first year. An import wizard ingests the spreadsheets a landlord already keeps: units, tenants, leases, and past payments. A client can see twelve months of arrears, collections, and occupancy in their first session, which is also how they find out whether the system agrees with their own numbers.
Built for the compliance the market is moving towards
KRA-oriented rental income reporting and eTIMS-ready invoicing are in the data model rather than bolted on, because a report you cannot produce is a report you will be asked for. The platform is registered with the ODPC, tenant data is hosted in Kenya, and data-subject rights are product features rather than a policy page.
Where it stands today
Live and in early access. Onboarding is one managing company at a time, deliberately: the reconciliation engine only earns trust by being right about somebody's actual rent, and that is a conversation rather than a signup queue. Web and mobile run on one backend. The outcome numbers that would look good here (days saved at month-end, share of payments auto-matched) are not published yet, because none of them belongs to us until a pilot client has checked them and agreed we can. It is our own money funding it, so it ships when it is right.