Property Management Software Development: What It Costs and What Moves the Number

Three questions set the budget for property management software, and everything else is detail hanging off them. Does your tenancy model already version? Is service charge in scope? And how is client money held today? Answer those three and the number lands inside a band you can plan against. Leave them open and every quote you receive is a guess wearing a decimal point.

Here is the band. A phase one build for a managing agent keeping its accounting core and taking tenancy, charges and service charge in house runs 1,380 hours across seven modules. At $40 per hour that is $55,200. At $100 per hour it is $138,000. At a $65 blended rate, about $89,700. Move any single module and you can see what it does to the total, because every line is published below with its own range.

Most buyers start by asking for a feature list. That is the wrong start, and it is why so many of these projects land 40% over. A feature list prices screens. The cost of property management software is not in its screens. It is in whether the data underneath them can represent a tenancy that changed on a date, and whether the money that moved through it can be reconstructed per landlord three years later.

The ordinary failure is not dramatic. It is a rent review applied on the 1st when the lease says the 15th, discovered eight months later by a landlord reading a statement, affecting 300 tenancies, with no way to say what the correct figure should have been because the system only stores what the tenancy is now.

A tenancy is a versioned object, not a row

The single largest swing in the entire build is whether your tenancy model already versions. If it does, the work ahead of you is integration. If it does not, effective dating has to be introduced underneath a live rent ledger, and nothing on this page costs more to add late.

A tenancy is not a record that gets edited. It is a sequence of states, each true for a period. The rent was £1,200 until 14 March, then £1,290. The tenant was one person, then two. The managing agent changed in year three. A system that stores the current state and overwrites the rest cannot answer the only question that matters in a dispute: what did this tenancy say on the day the charge was raised?

Effective dating is the mechanism. Every tenancy fact carries the date range over which it holds. Reads take a date, not just an ID. "What is the rent" becomes "what was the rent on 14 March", and both the statement engine and the arrears calculation ask that question rather than reading a column.

Retrofitting this is expensive because it is not a schema change. It is a schema change plus a backfill plus every read path in the system plus a reconciliation proving the new history reproduces the old balances. The tenancy and lease model is budgeted at 240 hours in the worked example, inside a published range of 200 to 340, and that range assumes you are building it, not excavating it.

The charge schedule is an engine, not a form

A monthly rent with an annual uplift is a different piece of software from stepped, indexed and conditionally reviewed commercial terms, and the difference lands in the schedule generator rather than in the interface.

Residential is largely arithmetic: a figure, a frequency, an uplift date. Commercial is a rules engine. A lease may step at fixed points, index against a published rate with a cap and a collar, review to open market value on a cycle, and do two of those at once with a defined order of precedence. The generator has to produce a schedule of future charges that a human can audit line by line, and it has to regenerate that schedule when a review lands late and applies retrospectively.

Retrospective application is the part people forget. A rent review agreed in November with an effective date in June does not produce a single adjustment. It produces a recalculation of every charge raised since June, a delta per period, and a decision about whether that delta is invoiced, credited or spread. That logic belongs in the engine, not in a spreadsheet one person maintains.

The charge schedule, indexation and rent review engine is budgeted at 200 hours, inside a range of 160 to 280. The upper end is commercial portfolios with mixed review types.

Client money is an append-only ledger

How client money is currently held decides whether this module is bounded work or an archaeology project. Building a per-landlord position from a system that already separates balances is bounded. Reconstructing one out of a pooled history is not bounded, and is sometimes not possible at all.

The requirement is ordinary double-entry discipline applied to money that is not yours. Every receipt, every disbursement, every fee and every transfer is an immutable entry. Corrections are reversing entries, never edits. The per-landlord position at any past date is derivable by replaying entries up to that date, and the sum of landlord positions reconciles to the bank.

If the ledger can be edited, it is not a client money ledger. It is a report, and a report cannot be audited. This is why the module sits in Postgres as an append problem before it is a product one, and why the client money ledger and reconciliation module is budgeted at 220 hours, inside a range of 180 to 300.

One caveat worth stating plainly, because it changes what you are buying. We build the ledger; we do not hold client money, we are not a credit reference agency, and we do not transmit statutory filings or e-invoices on your behalf. Those are regulated activities with their own licensing, and a software vendor claiming otherwise is selling you a problem.

Service charge is a second model, not a report on the first

The most common scoping error in this category is treating service charge as a view over the rent ledger. It is not. Apportionment schedules, base years, expense stops and gross-up provisions are a second model with its own data, its own year end and its own reconciliation.

A service charge year runs on a budget, collects on account through the year, then reconciles actual expenditure against what was collected and issues a balancing charge or credit per tenant. The apportionment is rarely a simple percentage: it varies by schedule, by what each tenant's lease includes, and by whether a unit was occupied for the whole period. Commercial leases add caps, exclusions and gross-up clauses that change the number before it reaches the tenant.

If service charge is in scope it adds real scope, budgeted at 190 hours inside a range of 160 to 280. If it is out of scope, say so in writing during discovery, because it is the single most common source of a phase two that costs more than phase one.

Arrears, notices and the audit trail

Arrears is where a property system stops being an accounting tool and becomes a legal one, and that is why the notice logic has to live outside the transaction path.

The sequence is ordinary until it is not. A charge falls due, a payment does not arrive, a reminder goes out, then a formal notice, then a process with statutory timing attached to it. The arithmetic is trivial. The difficulty is that the rules governing what you may send, after how many days, in what form and with what information attached, vary by jurisdiction and by tenancy type, and they change. A system that hard-codes a notice period into the code path that raises charges will need a developer every time a rule moves.

Keep the rules in data and the sequence in code. Notice types, their qualifying conditions, their timing and their required contents belong in a rules model that an operations lead can read and an auditor can inspect. The transaction path asks that model what is permitted today. One jurisdiction is a section of work. Three is a programme with its own rules model, and it stays affordable only if that separation was made at the start.

The audit trail is the other half of the same requirement. Every charge, every notice, every write-off and every adjustment records what happened, when, under which version of the tenancy, and on whose authority. This is not logging. Logs are for engineers and get rotated away. An audit trail is a product feature with a retention period, queryable by a non-technical user who is answering a landlord's question or a regulator's, and it is the artefact that makes a disputed balance a five-minute answer instead of a week of reconstruction.

This is also where the versioning investment pays back. A trail that records the tenancy version in force at the time of each charge can explain any historical figure without anyone guessing. A trail that only records the action, against a tenancy whose terms have since been overwritten, explains nothing. Arrears, notices and possession workflow is budgeted at 150 hours inside a range of 120 to 220, and portals, reporting and the audit trail at 170 hours inside 140 to 240.

Phase one, module by module

Here is the whole thing added up. Every one of the seven sits inside its own published range, so you can move any line and see what it does to the total.

Module	Worked example	Published range
Tenancy and lease model, with versioning and effective dating	240 h	200 to 340
Charge schedule, indexation and rent review engine	200 h	160 to 280
Client money ledger and reconciliation	220 h	180 to 300
Service charge budgeting and annual reconciliation	190 h	160 to 280
Arrears, notices and possession workflow	150 h	120 to 220
Integrations: accounting core, payments, referencing, portals	210 h	180 to 320
Portals, reporting and the audit trail	170 h	140 to 240
Total	1,380 h	1,140 to 1,980

At $40 per hour that is $55,200. At $100 per hour, $138,000. At a $65 blended rate, about $89,700. The full span across the seven modules is 1,140 hours at every minimum to 1,980 at every maximum, which is the honest width of the estimate before discovery narrows it.

Quality assurance sits outside that number, at 20 to 25 percent of build. So do environments and deployment at 80 to 160 hours, and security review and penetration testing at 60 to 120. Those three are not optional on a system holding client money, and a quote that omits them is not cheaper, it is incomplete.

What actually moves the number

Seven things move this estimate, and only one of them is the feature list.

Whether the tenancy model already versions is the largest swing, for the reasons above. How client money is currently held is the second, at 180 to 300 hours depending on whether a per-landlord position can be derived or has to be reconstructed. Which core you keep, and what it exposes costs 80 to 200 hours per integration, and the figure depends on your vendor's API surface at your specific version, not at the version in the current documentation. That last distinction is the most common source of a mid-build surprise.

How many charge types and how variable decides whether the schedule generator is arithmetic or a rules engine. How many jurisdictions, and which notices turns one section of work into a programme with its own rules model, and it stays affordable only if the notice and cap logic was kept out of the transaction path. How many live tenancies migrate scales with the variety of terms rather than the count, so a small commercial portfolio can cost more to migrate than a large residential one.

What sits outside phase one

Three things are usually phase two, and they are listed rather than dropped because any honest scope argues for all of them eventually.

Lease accounting output for IFRS 16 or ASC 842 runs 120 to 240 hours. If your tenants or your own entity report under either standard, the lease data you already hold is most of the input, and producing the schedules from the system beats rebuilding them in a spreadsheet each year. Building systems and metering integration runs 100 to 220 hours and is what turns recharged utilities from an estimate into a measured figure. Portal distribution runs 60 to 120 hours.

Phasing these is a budget decision, not an architectural one, provided the tenancy model versions from day one. If it does not, every one of them gets more expensive to add, which is the same point this post keeps returning to because it is the one that costs the most to get wrong.

Build, buy, or keep the core and build around it

Most operators should not build an accounting core. Established packages do general ledger, VAT and statutory output better than a bespoke build will, and that part of the problem is not where your business differs from anyone else's.

Where a build earns its keep is the tenancy layer: the lease model, the charge engine, the service charge reconciliation and the audit trail. These encode how your portfolio actually works, and they are exactly where off-the-shelf property packages force you to change your operation to fit their assumptions about what a lease looks like.

The scope priced above assumes that split: keep the accounting core, build tenancy, charges and service charge in house, integrate the two. That is why the integration module carries 180 to 320 hours and why the discovery produces an integration inventory before anyone produces a number. The stack we use for this is Python with FastAPI, Node, PostgreSQL and Next.js, with Terraform for infrastructure and Grafana and Prometheus for metrics. Postgres carries the tenancy versions and the client money ledger, because both are append problems first.

Where these builds actually fail

They do not fail on the interface. They fail in four places, and all four are decided before anyone writes code.

The tenancy model does not version, so the system cannot answer what a lease said on a past date, and every dispute becomes a manual reconstruction. The client money history was pooled, so a per-landlord position cannot be derived, and the migration stalls on data that does not exist rather than on code. The accounting core's API turns out to differ at your version from the published documentation, and an integration budgeted at 80 hours runs to 200. Service charge was assumed to be a report, and reappears as a second data model halfway through the build.

None of those is a surprise if discovery looks for them. All four are expensive to discover afterwards. That is the entire argument for refusing to quote before the integration inventory exists and the tenancy model question has an answer: not caution, but the fact that these four items carry more of the variance than every feature decision combined.