Every comparison of property-management software is a feature grid, and every feature grid is mostly ticks. That is not because the products are the same. It is because the things that actually decide whether you will be happy in three years do not fit in a cell.
Having migrated a real portfolio and helped other operators do the same, here is what I would actually weigh.
1. Can you get your data out?
Ask this first, before anything else, and ask it specifically: is there a documented API, and does it cover the things you care about — payments, charges, work orders, statements? Not “do you have an API”, which everyone says yes to.
This is the single question that decides how much of your future is in your own hands. A system you can read from is a system you can build reporting on, automate around, and eventually leave. A system you cannot read from owns you, and every problem becomes a support ticket and a wait.
2. How much of your work does it genuinely not do?
Every operator has a spreadsheet beside the system. Ask what yours would be. Inspections? Turns? Voucher programmes? Lockboxes? Owner reporting?
That gap is your real cost, and it does not show up in the subscription price. It shows up in staff hours, and it grows with your door count while the software price grows more slowly. Most people choose on the monthly fee and pay for it in payroll.
3. What does the migration actually cost you?
Not the quoted fee — the disruption. Ask specifically what transfers and what is rebuilt by hand: open charges, prepayments, deposits held, partial-month prorations, work-order history, owner statements, documents. The answer is almost never “everything”, and the difference is weeks of somebody’s life.
And ask how far back the history comes. A migration that carries balances but not history means that for the first year, every dispute about something that happened before the cutover is answered by opening the old system — which you are still paying for.
4. Does it match how you are actually organised?
Some systems assume one pooled team. Others assume portfolios with a manager each. If the software’s model does not match yours, you will either reorganise the company around the software, or fight it every day. Both are expensive; the first is at least honest.
5. Trust accounting, seriously
If you hold client money, the accounting is not a feature — it is the regulated core. Ask how it handles owner-level versus property-level ledgers, reserves, and the reconciliation your state actually requires. A system that is beautiful everywhere else and awkward here will cost you at the worst possible moment.
So what would I pick?
It depends on your size and how much you intend to build, and anyone who answers without asking those is selling something:
- Under a few hundred doors, no appetite to build: pick for the accounting and the support, and accept the gaps.
- Growing, and willing to build: pick for the API. It will matter more every year, and it is the one thing you cannot add later.
- Large and complex, with real compliance: pick for the accounting and the programme handling, then budget for the integration work, because there will be some.
The honest summary: the feature grid tells you what a product does today, and the API tells you what you will be able to do with it for the next five years. One of those is on every comparison page and the other almost never is.
If you are weighing a change and want a second opinion from someone who has done it rather than sold it, email me.