Property and tenancy platforms
rentiQ
Our own product, live
The hard part: Every payment, however it was recorded, is allocated by one engine against the oldest unpaid invoice, so the arrears figure has one answer.
Work
Systems we built, told in full.
We would rather show you systems we designed and built than a wall of logos. There are three here, one for each kind of system we lead with. rentiQ is our own SaaS, so we can tell you how it is put together and which parts were harder than they looked. The other two are client platforms, written up without the client's name: one we still run under a support agreement, and one we built and handed over. Below them is the founder's record, which is a separate thing and is labelled as one.
Case studies by pillar
Booking and scheduling engines
The calendar is also the ledger
Client platform, built and handed over
The hard part: An appointment is a financial event, so the calendar and the ledger move together or not at all.
Operations and compliance platforms
One workforce, three calendars
Client platform, supported under SLA
The hard part: Three modules draw on one workforce, and an impossible booking is refused before it exists.
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.
Free, no call required
The payment reconciliation checklist
35 questions to run against your own payment reconciliation, from partial payments and duplicate callbacks to suspense ageing and whether the ledger ties to the bank statement.
02 / Founder track record
The engineer behind every build.
The case studies above are the studio's. Over 7 years, its founder has also built and run production software for other employers and clients, before and outside this company. That record belongs to David Kimani personally, so it lives on his own site and is linked rather than reprinted here.
What it buys you: the person architecting your system has already made these mistakes at somebody else's expense.
- Shipped, career total
- 27+ production apps
- Experience
- 7 years
- Where it lives
- davidkimani.dev/work ↗
Apart from the studio's own internal systems, which it also lists, the applications on davidkimani.dev that are not written up on this page were built before and outside Kimcard Technologies, for other employers and clients. They are listed as the founder's track record, never as this company's work.
Next step
Bring us the system your operation runs on.
You get a senior engineer who has shipped this kind of software before, a studio small enough that the person who scoped your work is the person who builds it, and systems in production that we have to keep running whether or not it is convenient.
The first call is free and takes 30 minutes. We reply within one business day.