Tenancy and rental management
Properties, units, tenancies and the money that moves between them — rent raised on a schedule, payments matched against it, deposits held separately, and every agreement carrying its own renewal and inspection dates.
Built for someone running property as a business rather than as a side ledger: several units, overlapping agreements, and an accountant who needs the year to reconcile without a rebuild.
Talk about scopeA tenancy is a contract with a clock on it
The hard part is not storing a rent figure. It is that a tenancy has a start, an end, a notice period, a rent that changes mid-term, a deposit held under rules that are not the landlord's to bend, and a renewal that has to be raised before a date nobody is watching for. Model it as a property with a monthly amount and every one of those becomes a manual reminder — which is exactly the spreadsheet the software was meant to replace.
What we would build
Money matched, not just recorded
Rent is charged on a schedule and paid in amounts that rarely line up with it — part payments, late payments, one transfer covering two months, and a deposit that must never be counted as income. The work is the matching: an arrears figure is only trustworthy if the system knows which charge each payment settled, and in what order.
Dates that raise themselves
Agreement renewals, notice deadlines, safety inspections and certificate expiries are all known in advance and all missed the same way — by being someone's job to remember. These belong in the system as scheduled obligations that appear before they are due and stay visible until closed, rather than as fields somebody is expected to read.
When not to build this
A packaged product is the right answer more often than a development company usually admits, and if your problem is an ordinary one that something off the shelf already solves, we will tell you so rather than quote for it. What follows is the case for the other answer — the conditions under which building is worth what it costs.
The workaround has become the process
A packaged system that mostly fits leaves a residue — the spreadsheet kept alongside it, the step done by hand every month, the field used to mean something it was not named for. When that residue is where the actual work happens, you are already maintaining custom software, just without any of the benefits of having built it.
The thing you do differently is the thing it cannot do
Every business has a few processes that are genuinely its own, and those are usually the ones it competes on. Off-the-shelf software is built for the average of a sector, so it handles the ordinary parts well and the distinctive part not at all. Building is worth it exactly where that overlap fails, and rarely anywhere else.
A vulnerability shared by every deployment
A vulnerability in a packaged product is a vulnerability in every deployment of it, and attackers only have to find it once. A system built for one business is not on that list.