Tenant Manager

Rent Tracking and WhatsApp Reminders for a Family Property

Solo Engineer · Next.js + Supabase · May – Oct 2026

Overview

A private application replacing the spreadsheets and memory used to run a family rental property. It tracks tenants, computes monthly rent including scheduled increases, records payment status and history, and sends rent reminders over WhatsApp.

The users are relatives, including a non-technical grandmother. That shaped nearly every decision: no accounts, no signup, no password reset flow. Sensitive data and write actions sit behind two shared numeric PINs enforced on the server, which is enough security for the actual threat model without putting a login wall in front of someone who just wants to check whether the rent came in.

The public demo runs the same code on an invented household: six tenants named after the space they rent, two years of rent history, and both PINs printed at the top of every page so visitors can try every tier. A guide on each screen points out what to look at, such as the tenant who never paid a month from three months back.

It shares a codebase with the household expense module, both reached through a common hub.

Next.js 16 React 19 TypeScript Supabase PostgreSQL Tailwind 4 WhatsApp Vitest

Problem & Solution

The Problem

Rent tracked across spreadsheets and phone conversations
Scheduled rent increases applied manually and forgotten
Reminders sent one tenant at a time, by hand
Non-technical users who will abandon any login flow
Sensitive tenant data with no access control at all

The Solution

One dashboard showing paid, late, and pending at a glance
Rent computed from the schedule, not re-entered each month
One-tap WhatsApp broadcast to every tenant
No accounts — two shared PINs, server-enforced
Locked viewers get a degraded response, not an error page

Key Highlights

Rent Computation
Monthly rent derived from each tenant's terms and their scheduled increase dates, so raises take effect on their own without anyone remembering to apply them

Two-Tier PIN Auth
A family PIN for viewing sensitive fields and an admin PIN for write actions, hierarchical so admin satisfies everything family can do

Signed Sessions
HMAC-signed thirty-day tokens built on Node's own crypto module, adding no dependency; rotating the admin PIN invalidates every outstanding session of both tiers at once

Graceful Degradation
Without a PIN the dashboard simply omits phone numbers, deposits, and bank details rather than refusing to load, and reports which version the client received

WhatsApp Worker
Reminder broadcasts and monthly greetings run through a separate local service authenticated by scanning a QR code once, keeping a browser automation dependency out of the web app

Migrated Off Sheets
Moved from a Google Sheets backend to Supabase, then deliberately removed the migration-era compatibility shims once they were no longer earning their keep

Tap-to-Send WhatsApp
A phone-friendly path for when the laptop worker is off: pick a reminder or greeting, tap each tenant, and WhatsApp opens with the message already typed, marking who has been sent so far

Public Demo
The same code runs a public demo on an invented household generated relative to today, rebuilt every night so it never goes stale and visitors' changes are wiped

Technical Approach

Enforced a strict architectural rule that all business logic lives in the server library or API routes, with components reduced to fetch-and-render — and backed it with a refactor that relocated roughly ten pieces of stray logic out of components
Designed the PIN check to verify the admin secret before the family one, so a misconfigured overlap grants the higher tier rather than silently downgrading a user
Signed session tokens with the admin PIN regardless of which tier unlocked them, making PIN rotation a single-step revocation of every live session
Parsed the cookie header directly instead of using the framework's request-context helper, so route handlers can be unit tested by calling them with a plain request object outside any server context
Made unlock prompts check the live session before opening, so a page with several gated buttons prompts once per session rather than once per click
Returned an explicit wrong-tier error when a valid family PIN is submitted against an admin-only action, instead of accepting it and failing further down
Kept the locked-state expense totals accurate across the full month even while the line items themselves are withheld, so an unauthenticated viewer sees real numbers without the private detail
Isolated the WhatsApp integration in its own process on a separate port, so a browser-automation crash cannot take down the web application
Generated the demo household from calendar rules with randomness seeded by date and rule, so each night's rebuild produces the same household with one more day of history rather than a reshuffled one
Guarded the nightly demo reset three ways — a demo-mode flag, the cron secret, and a marker table that exists only in the demo database — because the route deletes everything and ships in the same build as the family app
Built 61 test files covering the rent math, access tiers, insights, API routes, and derivation logic that would otherwise be invisible until a month-end mistake

What This Demonstrates

Right-Sized Security: Chose two shared PINs over real authentication after reasoning about the actual users and threat model, then enforced that choice properly on the server rather than hiding buttons on the client
Architectural Discipline: Set a clear logic-placement rule and enforced it with a real refactor, keeping the codebase testable as it grew
Designing for Real Users: Optimised for a grandmother checking rent on a phone, which ruled out patterns that would be automatic in a commercial product
Testability as a Constraint: Made deliberate implementation choices, like hand-parsing cookies, specifically so route handlers could be tested without a framework harness
Migration Hygiene: Moved backends and then went back to delete the compatibility layers, rather than leaving them to rot as permanent complexity
Failure Isolation: Separated a fragile third-party integration into its own process so its failure mode is a clear error on two buttons, not an outage