Should Your Property Management Company Build Its Own Software?

• Most property management companies shouldn’t build their own software. The ones who should are building one specific piece of it, not the whole thing.

• Your back-office system of record, the rent ledger, the trust accounting, the compliance trail, is the piece to keep renting. Rebuild it and you’ve bought a worse version of something that already works.

• The layer worth a second look is the surface on top: the portal every owner, resident or board member needs a paid seat for.

• Per-seat pricing indexes your software bill to the exact thing you’re trying to grow. That’s structural. It isn’t a negotiation you win at renewal.

• Before you cost a build, split twelve months of software invoices into two columns: what you pay to run the business, and what you pay per person who logs in.

• If nobody inside your company will own the thing on the Tuesday after launch, the answer is no, whatever the two columns say.

You took on more doors last year and the software bill went up with them. It always does, and rarely in a straight line. Somewhere in that renewal conversation somebody says the thing everybody eventually says: we could just build our own. That instinct is usually wrong, and it’s worth understanding why before you pay anyone to find out for you.

Most property management companies shouldn’t build their own software. That belongs at the top of the page, not buried at the end of a balanced list. It isn’t a comment on your business or your ambition. It’s a comment on what you’d be replacing.

What people usually mean by “our own software” is the system of record. That’s where the rent ledger lives, where trust or escrow accounting is enforced, where owner statements and year-end tax reporting come from, and where the audit trail sits when a regulator or a board asks a question. It’s dense, unglamorous software carrying decades of small rules. Nobody notices it working until the day it stops.

The part that ends these projects is never the build. It’s year three. Launch day is the day maintenance starts, and maintenance here isn’t optional polish. Payment file formats change. Tax reporting changes. A provincial or state rule changes what a notice has to say. Somebody has to answer the phone on the first of the month when payments haven’t posted. Your vendor absorbs all of that today and spreads the cost across every company that uses it. Build it yourself and you’ve hired that obligation permanently.

There’s a second reason, and it’s the less obvious one. A system of record is the least differentiated part of a property management company. Nobody has ever chosen a manager because their general ledger was better. Put your one serious software budget there and you’ve spent it on the part of the business your clients never see.

Two pricing shapes sit inside that invoice, and they behave differently as you grow. Part of it is priced per unit or per door, so it tracks the portfolio directly. The rest is priced per seat, meaning per person who needs a login, or per active user, or by a tier you quietly outgrow.

The per-unit half is a fair trade. You add doors, you pay more, and you’re being paid more for those doors. The per-seat half stops tracking anything you earn, because the people who need access aren’t the people generating the fee.

The vendors aren’t hiding this. AppFolio reported that in the second quarter of 2026 its revenue grew 19 percent year over year while total units under management grew 8 percent. Revenue rose more than twice as fast as the doors underneath it. The same release puts value added services at 22 percent growth against subscription services at 16, led by risk mitigation, tenant screening and online payments. That’s where the money is. Not in charging you more per door, but in what gets sold on top of the doors. It’s a well run business model. It just isn’t yours, and it compounds against you every year you stay in it.

If you manage community associations the arithmetic is sharper, because the seat count isn’t your staff. It’s every owner and every board member in every association on your books. The Foundation for Community Association Research counts roughly 373,000 community associations in the United States at the end of 2025, housing close to 80 million people and about a third of the national housing stock. Whatever share of that you manage, the people who need a login outnumber your payroll by a margin nobody says out loud on a renewal call.

Buy or build is the wrong frame. It forces one answer onto two very different pieces of software. Draw your stack as two layers instead.

The bottom layer is the system of record. Rent, ledgers, accounting, compliance, money movement, the reporting that has to survive an audit. Rent that layer and keep renting it. It’s the part where being ordinary is the goal.

The top layer is the surface. It’s what an owner sees when they check a statement, what a resident sees when they report a leak on a Sunday night, what a board sees when it approves something. Maintenance requests, documents, approvals, statements, notifications, the mobile app with your name on it. That’s the layer your clients judge you on, and usually the layer you have the least control over.

It’s also the only layer where building occasionally makes sense. A portal is a far thinner problem than a general ledger, and it can read and write to the system underneath through an API instead of replacing it. But the reason that decides it is the money. The per-seat cost lives up here, so it’s the one place where a build has a real number to argue against.

Operators who have done this and written about it describe building on top rather than instead. In its annual filing for 2022, Tricon Residential, then a Toronto-headquartered single-family rental operator, set out a proprietary suite of applications it developed itself, including one for coordinating repairs and maintenance across field personnel, centralized office staff and third-party vendors, and told investors the platform was difficult to replicate. What the filing does not describe is an operator rewriting its own accounting. The sequence is the part worth copying. Define the boundary between the two layers first, then the scope, then a number. That’s what we work through in product strategy for property management, before anyone commits to a build. And a portal nobody logs into is its own failure mode with its own causes, which is why nobody uses your resident portal.

A minority of companies genuinely should build, and they can answer all five of these without flinching. If you can’t answer one of them yet, you’ve found your next piece of work rather than your next project.

1. Can you name the seats, and are they growing faster than your revenue?

Pull the last twelve months of invoices and separate the per-unit lines from the per-seat lines. If the per-seat half is flat or small, there’s nothing here worth building against. If it has grown faster than your management revenue over the same period, you’ve got a real number instead of a feeling.

2. Is the thing you want to build a surface, or the ledger under it?

Write down what the new software would hold. If the answer includes the rent ledger, trust accounting or year-end reporting, stop. Those belong to the layer you keep renting. If it’s what people see and do, you’re in the right layer.

3. Will your back-office system let you read and write through an API?

This is the question that quietly decides the project, and most people ask it last. Get your vendor's API documentation before you talk to a single developer. If the data only comes out as a nightly file, or comes out and never goes back in, this is a much harder build than you think. The honest finding may be that the layer underneath has to change first.

4. Is there something you do that nobody sells?

Not “we want it to look like us.” A specific piece of how you operate that no vendor has a screen for. A move-in process, or an owner reporting rhythm clients stay for. If every requirement on your list already exists in a product you could buy this afternoon, buy it. Custom software earns its cost where you’re genuinely different, and nowhere else.

5. Who owns this on the Tuesday after launch?

Name the person. Not the agency, not the developer. The person inside your company who decides what gets fixed first when two things break in the same week. If that name doesn’t exist, the answer is no, and it stays no until it does.

Here’s how the three real options compare once you have those answers.

If the five questions came back clean, price the work honestly. The build is the visible part. It isn’t the risky part. The risky parts are these:

• Two-way data sync with the system of record, and a decision about which system wins when the two disagree. This is the most common place these projects come apart.

• Identity for people who aren’t your employees. Every resident and owner has to get in, reset a password, and lose access on the day they move out. That last one is a compliance problem wearing a feature's clothes.

• Money. Most companies shouldn’t build payment handling. Leave it with the processor or the back-office vendor and link out to it.

• A support queue for software, staffed by people whose job is currently something else.

• App store releases and operating system updates, which arrive on somebody else's schedule for as long as the app exists.

Then there’s adoption, the line nobody budgets. Buildium's 2026 Property Management Industry Report found AI adoption among property managers jumped from 20 percent in 2024 to 58 percent in 2025, while only 8 percent of companies had fully automated any process. Buying a capability and changing how the work happens are two different projects. The second one is harder. A portal your residents ignore costs more than the one it replaced, because you’re paying for it and still answering the phone.

Which is why the contract shape matters more here than the technology choice. A build with a defined scope, written acceptance criteria and a change process is a different risk from the same build quoted off a conversation. We went through that in the piece on contract structure and scope creep. If question one turns up a process problem dressed as a software one, the three-step plan for upgrading how your business works is the cheaper place to start.

Start with what sits underneath all of them. You serve three groups at once, and almost every piece of software you own treats them as variations of one user. The owner or the board pays your fee and can end the contract. The resident generates most of your daily work, didn't choose you, and can't easily leave. Your own coordinators absorb whatever the other two can't do themselves, and nobody surveys them, which is why they quietly set your capacity.

In most businesses the person who creates the work is the person paying for it. Here they aren't, which is why one underlying complaint reaches you in three different shapes.

The first is the shape of the cost. You feel it at renewal, it grows with a number somebody else counts, and the honest answer to what you'd change about your software is the invoice. That one is a counting exercise before it's ever a build.

The second is the surface. What a resident opens on a phone, what an owner logs into, what your coordinator stares at for six hours a day. It's the layer where your firm is genuinely different from the one across town, and the one you control least, because it arrived attached to the accounting underneath it. Those two layers get sold as a single product, which is why this question keeps getting asked as all or nothing when it isn't.

The third is that the work happens in buildings, and the record of it lives with people rather than in a system. A repair gets reported in a hallway, done by a vendor who doesn't work for you, and closed by a superintendent who mentions it to somebody. The office keeps whatever survived that trip, which in a lot of firms means personal phones and one person's inbox. Fine, right up until somebody asks you to produce it.

Only the second one is obviously a software project. The first is arithmetic, and the third is as much about who owns a step as about which tool they use.

Look at who keeps raising it, and how often. If it's your finance lead, once a year, at renewal, that's the first problem, and it gets settled with a spreadsheet rather than a project. Put your door count and your annual software bill on the same chart for the last three years, then put revenue per door beside them. If the first two lines are parallel and the third isn't, you've found something worth going to look at properly.

If it's owners or a board raising the same thing repeatedly, or residents phoning about something they could have looked up, that's the surface. The question worth asking is whether what they want has a field for it in what you already run. Something the platform has no concept of is a far stronger case than something it does awkwardly.

And if the complaint is that nobody can say what happened, when, or where the photo went, it's the third. Take one routine repair from the resident's first message through to the vendor's invoice being coded, and count every point where somebody retyped something. That number tells you whether this is a software problem or a process problem. If work orders aren't being logged today, a better tool won't get them logged.

Take twelve months of software invoices and draw two columns. On the left, everything you pay to run the business: the ledger, the accounting, the compliance reporting, priced per unit or per door. On the right, everything you pay per person who logs in.

Then compare each column's growth against your own over the same twelve months. If the left column grew roughly in line with the portfolio, that’s the system working as intended. Leave it alone. If the right column outran both, you’ve found the layer worth a conversation, and you’ve found it with a number attached instead of a hunch.