Web · Next.js 16 · Neon Postgres · Vitest · Municipal program tooling
Rental Inspection Compliance
When a deadline carries legal weight, it belongs in one tested function.
A rental registration and inspection scheduler for a fire department running a residential rental program. It tracks registration status, inspection and re-inspection deadlines, and — just as importantly — documents the department's attempts to contact property owners. The compliance rules are unusual, legally significant, and consequently isolated into one pure function covered by tests so a future rewrite cannot quietly break them.
- Next.js 16 (App Router)
- TypeScript
- Tailwind CSS 4
- Neon Postgres
- Vitest
- Resend
Origin
How it started
I am a firefighter. The rental inspection program was being tracked the way most small-city programs are tracked, and the deadlines in the ordinance are genuinely intricate — they interact, they have exceptions, and in a few places they contradict each other. Building the tool meant reading the code of ordinances closely enough to compute dates from it, which turned out to be an exercise nobody had done end to end.
Features
What it does
One compliance engine, many views
A single pure function with no database access decides whether a unit is compliant. Every queue, dashboard, and notification renders its output rather than re-deriving it. Rules that carry legal weight get exactly one implementation.
Calendar dates, never instants
Every date column is a date rather than a timestamp, month arithmetic clamps to end-of-month, and 'today' is read in the program's local timezone rather than the server's. A timezone bug here does not produce a rendering glitch — it moves a legally significant deadline by a day.
Documented contact attempts
Tracking the department's attempts to reach an owner matters as much as tracking the deadline, because due process is part of the program. The record is a first-class object, not a notes field.
Ordinance research as a deliverable
Encoding the deadlines produced a formal memo for the city attorney and building official cataloguing where the code is silent, ambiguous, or self-contradictory — each item noting what the system does in the interim so nothing is assumed silently.
Under the hood
Engineering
The rules are the product
The interesting engineering is not the CRUD around inspections — it is that a legal clock has one canonical implementation, expressed as a pure function with no database dependency and covered by unit tests. Inlining a threshold into a component, a SQL query, or an email template would scatter legal logic across the codebase where nobody would find it during a rewrite. Isolating it makes the rules auditable by someone who does not read TypeScript.
Research before code
The program had been recodified into a different chapter than the enacting ordinance created, split across divisions, and amended since. Establishing which text was authoritative — the codified version, not the standalone ordinance PDF — came before a line of scheduling logic. Software that computes legal deadlines from the wrong source of law is worse than a spreadsheet, because it looks authoritative.
Sharing a database without sharing a namespace
The program runs on a Postgres instance shared across several of my projects, with every table carrying a project prefix. Small-scale infrastructure discipline: one database, hard namespace boundaries, no cross-project migration accidents.