Real estate operations
Generates rent schedules from lease terms, allocates part payments the same way every time, and keeps a ledger per lease that both sides can read.
Build effort, not elapsed calendar time. Engagements ran alongside study and employment, so this figure is the work itself rather than the span it sat in.
Interface built in code for this case study — not a client screen capture.
01Business problem
Landlords and property managers run leases from a spreadsheet, which handles neither a part payment nor an escalation nor a mid-month move-in without someone doing arithmetic by hand.
Who feels it
A lease is a schedule of obligations, but a spreadsheet stores a monthly rent figure. The moment reality deviates — a tenant moves in on the eighteenth, a five percent escalation lands on the anniversary, a payment arrives for less than the amount due, a late fee applies — the sheet needs manual intervention, and different people intervene differently.
Part payments are where it breaks down completely. A tenant owing three months pays a partial amount. Applied against the oldest debt it clears an old month; applied against the newest it leaves the arrears aged. Both happen, inconsistently, and neither the landlord nor the tenant can reconstruct how the balance was reached. Disputes then come down to two spreadsheets disagreeing.
Meanwhile maintenance requests arrive by phone and message and are lost, deposits are held with no clear record of deductions, and renewal or notice dates pass unnoticed — the same forgotten-date problem that costs money in any contract-driven business.
02Product overview
A lease management system that generates a dated rent schedule from lease terms including pro-rata periods and escalations, records every charge and payment in a per-lease ledger, and allocates payments through one stated waterfall so a balance is always reproducible.
Engineering notes
A lease produces a schedule, not a monthly number. Terms — start date, end date, rent amount, billing day, escalation clause, deposit — generate dated charges, with the first and last periods pro-rated by day count and escalations applied at their anniversary. The schedule is generated once and stored as charges, so what a tenant owes is a set of dated records and not a formula someone re-evaluates each month.
Everything lands in a per-lease ledger. Rent charges, late fees, utility recharges, maintenance recharges, payments, credits and deposit movements are all entries, and the balance is their sum. Because the ledger is the source of truth, a statement is a read and not a reconstruction, and a landlord and tenant looking at the same ledger see the same history.
Payment allocation follows one waterfall, applied identically every time: late fees, then oldest outstanding charges, then current, with any excess held as a credit against future charges. The allocation is recorded per payment, so a tenant can see exactly which charges their money cleared, and a dispute becomes a question about a specific entry rather than a disagreement about a total.
Maintenance requests are tickets with a category, a priority-derived response target, vendor assignment and cost recording, with the option to recharge to the tenant where the lease permits it. Notice and renewal dates come off the lease term and appear as dated alerts.
03Key features
11 capabilities. Every one of them is deterministic software — there is no model in this build, and nothing here is described as AI.
Properties with units, attributes, ownership and current occupancy status in one structure.
Start and end dates, rent, billing day, escalation clause, deposit and the signed document held against the lease.
Dated charges generated from terms, with first and last periods pro-rated by day count and escalations applied at anniversary.
Charges, payments, fees, credits and deposit movements as entries, with the balance derived from them.
One stated order applied every time — fees, then oldest charges, then current — with the allocation recorded per payment.
Underpayments leave specific charges partially settled; overpayments are held as credit and applied to the next charge.
Fees applied from lease terms after a grace period, posted as ledger entries that can be waived with a recorded reason.
Deposits tracked separately from rent, with itemised deductions at move-out and a settlement statement.
Requests with category, response target, vendor assignment, cost and optional recharge where the lease allows it.
Dates derived from the lease term, surfaced with lead time so a renewal decision gets made and not defaulted into.
A statement generated from the ledger showing charges, payments and how each payment was allocated.
04User flow
The path from the trigger to the finished record, with each step attributed to whoever performs it — a person or the system.
05Architecture
The processing path first, then the layers it runs on, then the constraints that shaped both.
Path through the system
Property, unit and lease terms captured with documents.
Rent schedule produced with pro-rata and escalation applied.
Dated charges posted to the lease ledger; fees applied by policy.
Payments allocated through a single stated waterfall.
Tickets routed to vendors; costs recorded and optionally recharged.
Notice and renewal handled; deposit settled with itemised deductions.
Layers
Why it is shaped this way
06Technical decisions
Every decision here was contested by a reasonable alternative. The trade-off column is the part usually left out.
Why
A stored schedule can be adjusted for a real-world exception — a rent holiday, a negotiated reduction — without breaking a formula. It also means a tenant’s obligations exist as records that can be referenced by a payment.
Trade-off
Changing lease terms requires regenerating future charges while leaving posted ones alone. That is explicit logic, deliberately not a silent recalculation.
Why
Inconsistent allocation is the root of most rent disputes. A single stated order — fees, oldest charges, current, then credit — makes every balance reproducible and every statement explainable.
Trade-off
A landlord occasionally wants to allocate differently, so a manual allocation override exists and is recorded as such. The rule itself is never quietly changed.
Why
Pro-rating a month by day count and applying a percentage escalation both produce repeating decimals. Floating-point money accumulates drift, and in a rent ledger that drift becomes an argument with a tenant.
Trade-off
Rounding must be decided explicitly at each step, and the schedule generator assigns rounding remainders deterministically so a year of charges sums to the annual rent.
Why
A deposit is held money, not revenue, and netting it against arrears obscures both. Separating them makes the move-out settlement an itemised calculation rather than an adjustment inside a running balance.
Trade-off
Two balances to present, which the interface handles by showing them as distinct sections and never as a single figure.
Why
Fees get waived for good reasons. Posting them as entries and waiving with a reversing entry keeps both the policy application and the waiver visible, instead of the fee simply never appearing.
Trade-off
The ledger holds entries that net to zero — exactly the record needed to show that a fee was charged and then waived.
07Challenges
Not the setup work. These are the problems where the first implementation was wrong and had to be reconsidered.
Approach
Proration is computed on actual day counts in the affected month, in integer minor units, with the rounding remainder assigned to the final full period and never dropped. The generator asserts that the schedule sums to the expected total for the term and fails loudly if it does not.
Outcome
Schedules reconcile exactly, so a tenant adding up their charges gets the figure in the lease instead of one a rupee or two off.
Approach
Escalation is modelled as a typed clause — fixed percentage at anniversary, fixed amount, or scheduled steps — with the anniversary computed from the lease start, not the calendar year. Generation applies the clause forward through the term, and each escalated charge records the clause and the base it was applied to.
Outcome
A tenant asking why rent rose can be shown the clause, the base amount and the resulting charge from the record itself.
Approach
Allocation became a pure function over the ledger returning explicit allocation records per charge. The payment screen previews the allocation before it is committed, and the tenant statement shows, for each payment, exactly which charges it settled and by how much.
Outcome
Disputes moved from arguing about a total to examining a specific allocation, which is a resolvable conversation.
08Business value
Stated qualitatively on purpose. Invented percentages are the easiest thing to put on a portfolio and the easiest thing to see through.
Operational effect
What would change at scale
09Interface
Dense operational views rather than dashboards. These are used for hours at a time, so the priorities are legibility, keyboard flow and state that is never ambiguous.
Lease ledger
Charges, payments, fees and credits in date order with a running balance and the deposit shown separately.
Payment allocation
A preview of which charges a payment will settle, and by how much, before it is committed.
Rent schedule
Generated charges with pro-rated first and last periods and each escalation showing its clause and base.
Maintenance board
Tickets by priority with response target, assigned vendor, recorded cost and recharge status.
The screen above is built in HTML and CSS for this case study. It reproduces the layout, states and vocabulary of the real build without exposing client data, which is why it exists rather than a screenshot. It is evidence of design and of the decisions behind it. It is not a photograph of a deployed system, and no part of it is a capture of anyone else’s product.
10Technologies
Chosen for the shape of the problem, not for novelty. Anything unusual is justified in the decisions section above.
11Technical preview
There is no repository link on this site. What is available instead is the module structure, the data model, the interface contracts and annotated excerpts written for this case study — enough for a technical reviewer to judge the engineering.
Technical preview
Selected implementation details are available for technical review: component structure, data models, architecture notes and sanitized code excerpts. Some client-specific source material stays private because of confidentiality. Enter the project access keyword if you have been given one — the same one works across every case study.
A presentation convenience, not authentication. This is a static site, so the keyword ships to your browser with the page and anyone reading the bundle can find it — worth saying plainly rather than dressing it up. Nothing confidential is stored behind it.
Inside this section
For private client work, contact me for a walkthrough.
Next step
Send the process, the constraints and the deadline. You will get an honest scope, an architecture sketch and a timeline before any commitment.