Overview

K535 is a multi-tenant rental property management platform designed specifically around operational realities in the Kenyan rental market.

The system combines:

• property and unit management
• tenant onboarding
• lease lifecycle management
• invoice generation
• M-Pesa reconciliation
• SMS automation
• maintenance workflows
• realtime messaging
• operational analytics

into a single infrastructure-oriented SaaS platform.

The project was not designed as a simple landlord dashboard.

The primary engineering goal was building a system capable of supporting:

• isolated tenant organizations
• operational reliability
• financial reconciliation correctness
• workflow continuity
• realtime operational visibility
• infrastructure-level separation between services

under real-world rental management conditions.

Problem

Most property management systems focus heavily on CRUD interfaces and reporting dashboards.

However, real operational problems tend to emerge at workflow boundaries.

Common issues include:

• unreliable payment reconciliation
• duplicated M-Pesa transactions
• tenant communication failures
• inconsistent lease states
• weak tenant isolation
• operational workflows coupled too tightly to UI logic
• notification systems without delivery visibility
• realtime systems that fail under interruption conditions

Kenyan rental operations introduce additional constraints:

• M-Pesa-first payment behavior
• SMS-based tenant communication
• multi-property portfolio management
• operational staff separation
• partial payment handling
• delayed reconciliation windows

The platform needed to support those operational realities directly rather than treating them as secondary integrations.

System Philosophy

Multi-Tenant Isolation as Core Infrastructure

The platform was designed as a true multi-tenant SaaS system rather than a single-tenant dashboard replicated across users.

Every operational entity is scoped through:

• organization ownership
• Row Level Security
• organization-aware service layers
• protected mutation paths

This ensures landlords cannot accidentally access or affect another organization's operational data.

Deterministic Financial Workflows

Financial workflows were designed to prioritize correctness over convenience.

Critical operations such as:

• M-Pesa reconciliation
• invoice settlement
• duplicate detection
• balance computation
• payment matching

are handled through deterministic logic instead of loosely coupled frontend behavior.

Workflow Separation

The system intentionally separates operational domains.

Tenant-facing systems

• invoices
• maintenance requests
• payments
• messaging

remain isolated from:

Administrative systems

• portfolio management
• analytics
• reconciliation
• SMS automation
• operational reporting

This reduces unintended coupling between user workflows and administrative infrastructure.

High-Level Architecture

The project is divided into five major operational layers:

Layer

Responsibility

Tenant & Staff Interfaces

Operational UI workflows

Application Services

Feature orchestration and state handling

Edge Function Layer

Third-party integrations and background workflows

Data Infrastructure

Multi-tenant persistence and realtime systems

External Services

Safaricom Daraja and Celcom Africa integrations

Frontend Architecture

The frontend is built using React, Vite, and TypeScript with a feature-oriented structure.

The application separates functionality into modular domains including:

• properties
• tenants
• leases
• invoices
• payments
• maintenance
• messaging
• reports
• notifications
• SMS tooling

Each feature contains its own:

• components
• hooks
• services
• schemas
• types

Components never communicate directly with Supabase.

Instead:

• components call hooks
• hooks call services
• services communicate with Supabase

This keeps operational logic separated from presentation concerns.

Multi-Tenant Infrastructure

Tenant isolation is enforced at multiple architectural levels.

Every major table includes:

• organization_id
• scoped access policies
• organization-aware queries

PostgreSQL Row Level Security policies enforce isolation directly at the database layer using helper functions such as:

• get_my_org_id()
• get_my_role()

The service layer reinforces the same guarantees by ensuring all operational queries scope organization access explicitly.

This dual-layer model prevents accidental cross-tenant exposure even if application logic fails.

Payment Reconciliation System

One of the most operationally significant systems in the platform is the M-Pesa reconciliation pipeline.

The system integrates with the Safaricom Daraja Pull Transactions API to synchronize customer-to-business transactions.

The reconciliation workflow operates through several stages:

organization shortcode registration

transaction retrieval

pagination handling

invoice reference matching

duplicate transaction detection

payment insertion

invoice balance recalculation

payment status synchronization

Transactions are matched against invoices using structured bill references rather than manual reconciliation workflows.

The system also supports:

• sandbox and production environments
• per-organization credentials
• reconciliation logs
• idempotent transaction handling
• automatic invoice status updates

SMS Automation Infrastructure

The SMS system integrates with Celcom Africa to support operational communication workflows.

Supported workflows include:

• rent reminders
• overdue notices
• payment confirmations
• maintenance updates
• lease expiry alerts
• custom operational messaging

The platform includes:

• template management
• scheduled delivery
• delivery report polling
• failure tracking
• bulk messaging
• automation triggers

Every SMS event is logged and tracked through a structured lifecycle:

• queued
• sent
• delivered
• failed

This provides operational visibility into communication reliability instead of treating messaging as a fire-and-forget system.

Maintenance Workflow System

The maintenance module was designed as an operational coordination system rather than a simple ticket list.

Tenants can:

• submit requests
• upload images
• track progress
• receive notifications

Administrative users can:

• assign staff
• move requests through workflow stages
• manage priorities
• monitor resolution progress

The workflow uses structured state progression:

• Open
• Assigned
• In Progress
• Resolved

Realtime notifications and operational updates are synchronized through Supabase Realtime channels.

Realtime Communication Layer

The messaging system supports:

• direct messaging
• property group chats
• unread tracking
• online presence indicators
• realtime synchronization

Realtime delivery is powered through Supabase Realtime and Presence channels.

The system also implements optimistic updates so users see messages immediately while synchronization completes in the background.

This improves perceived responsiveness during operational communication.

Edge Function Architecture

All external integrations are isolated within Supabase Edge Functions.

Core functions include:

• mpesa-register-pull
• mpesa-query-transactions
• mpesa-callback
• send-sms
• check-sms-delivery
• scheduled-reminders
• send-notifications

The Edge Function layer acts as an orchestration boundary between:

• internal operational systems
• external APIs
• scheduled jobs
• background automation

Sensitive credentials remain server-side and are never exposed to the frontend runtime.

Data Model Design

The data model intentionally separates operational entities instead of collapsing everything into generalized records.

The schema separates:

• organizations
• properties
• units
• leases
• invoices
• payments
• maintenance requests
• conversations
• messages
• notifications
• SMS logs
• reconciliation logs

This improves:

• operational visibility
• debugging clarity
• reporting consistency
• financial traceability
• workflow observability

Key Engineering Decisions

Row Level Security Was Treated as Infrastructure

Tenant isolation was enforced directly at the PostgreSQL layer instead of relying entirely on frontend restrictions.

This significantly reduced the risk of cross-tenant leakage.

Financial Workflows Required Idempotency

Payment reconciliation systems needed deterministic duplicate protection.

M-Pesa transactions are therefore handled using:

• transaction ID uniqueness
• reconciliation logs
• repeat-safe synchronization flows

to prevent accidental double-processing.

External APIs Were Fully Isolated

Safaricom and Celcom integrations were isolated inside Edge Functions.

This ensured:

• credentials never reached the browser
• operational workflows remained centralized
• retries and failures could be controlled independently

Challenges & Tradeoffs

Reconciliation Reliability

Financial synchronization workflows become difficult once retries, duplicates, delayed transactions, and partial matches are introduced.

The reconciliation system needed to remain deterministic under inconsistent external API conditions.

Multi-Tenant Operational Boundaries

Tenant isolation affects nearly every architectural layer.

The project needed consistent separation across:

• queries
• policies
• notifications
• messaging
• reporting
• realtime subscriptions

A single incorrectly scoped query could compromise operational integrity.

Realtime Complexity

Realtime messaging and notification systems introduced synchronization challenges around:

• presence state
• optimistic updates
• reconnect handling
• unread counts
• subscription cleanup

The system needed to remain responsive without sacrificing correctness.

Current Status

RentMS Kenya is currently under active development.

Implemented systems include:

• multi-tenant infrastructure
• property and lease management
• invoice workflows
• M-Pesa reconciliation
• SMS automation
• realtime messaging
• maintenance workflows
• analytics dashboards
• operational notifications

Ongoing work includes:

• expanded financial reporting
• advanced automation workflows
• operational observability improvements
• reconciliation analytics
• infrastructure optimization
• tenant mobile experience refinement

What This Project Is

RentMS Kenya is best understood as:

A multi-tenant rental operations and financial workflow platform designed for real-world property management operations in Kenya.

Not:

• a simple property listing tool
• a basic landlord dashboard
• a generic CRUD management system

Its core focus is operational reliability, tenant isolation, reconciliation correctness, workflow continuity, and infrastructure-oriented rental management.

What I Learned

This project reinforced that operational systems become substantially more complex once real financial workflows and tenant isolation are introduced.

The difficult parts were not:

• forms
• dashboards
• UI components

The difficult parts were:

• reconciliation correctness
• idempotent workflows
• tenant isolation
• realtime synchronization
• operational visibility
• infrastructure boundaries

The project also reinforced an important architectural lesson:

Systems become significantly easier to maintain once operational responsibilities are separated clearly across infrastructure layers.

Separating:

• frontend workflows
• orchestration services
• reconciliation pipelines
• external integrations
• tenant isolation logic

made the platform substantially easier to reason about as the system expanded.