Two significant compliance changes are converging on the same window. HOTMA enforcement begins for most public housing agencies on 1 January 2027. NSPIRE compliance for voucher programmes is required from 1 February 2027, after a third extension. Both have been delayed repeatedly, which has left a lot of teams unsure what is actually required and when. This article sets out the current dates, what each rule changes in day-to-day work, and what has to be in place before the window closes. If you are earlier in the process, RIOO's guides to taking on public housing contracts and how platforms support public and social housing operations cover the decision and the tooling. Key takeaways HOTMA full compliance is now required from 1 January 2027 for both Multifamily Housing owners and most public housing agencies. Section 102 changes when income reviews happen. Section 104 introduces two asset thresholds, not one. NSPIRE has replaced UPCS and REAC inspection protocols. If your procedures ...

A vendor scorecard measures contractor performance using operational data rather than opinion. For property teams, that usually means five metrics pulled from work order history: first-time fix rate, response and completion against target, callback rate, cost variance against quote, and documentation completeness. Scored consistently within trade cohorts and run on a fixed cycle, it lets you compare maintenance vendors fairly, spot decline early, and hold a difficult conversation from evidence rather than from memory. Ask a property manager which of their contractors is best and you will get an answer immediately. Ask how they know, and the answer changes shape. He always picks up the phone. She sorts things out. They have been with us for years. None of that is measurement. It is familiarity, and familiarity is a poor proxy for performance. The contractor who answers the phone quickly may also be the one returning to the same unit three times a month. The one nobody likes talking to ...

Walk into almost any underperforming property operation and you will find the same diagnosis being offered: the tools are wrong. The software is dated, the systems do not talk to each other, the reporting is clunky. Buy better software, the thinking goes, and performance will follow. It usually does not. Portfolios replace their systems, sit through the implementations, and a year later the performance gap is roughly where it was. This is not because the new software was bad. It is because the problem was mostly not in the software layer to begin with. Here is the claim this piece defends. The persistent problems in property management, the rent left uncollected, the renewals allowed to lapse, the maintenance deferred, the efficiency investment never made, are overwhelmingly problems of incentive, not capability. They persist because the people in a position to fix them are not the people who benefit from fixing them. And no software can repair a structure where doing the right thing ...

When a property company evaluates software that runs on or alongside NetSuite, the word "native" shows up on nearly every vendor's slide, usually in a list of features next to things like reporting, mobile access, and automation. Presented that way, it reads as one desirable attribute among many, a checkbox you weigh against the others and trade off if something else matters more. That framing is the mistake. Native is not a feature sitting alongside the others. It is the architectural decision underneath all of them, the one that determines how every other feature behaves at month-end, across entities, and three years from now. And unlike a feature, which you can add or drop later, this is a fork you choose once, largely before you understand its consequences, and then live inside for the life of the system. Treating a foundational, near-irreversible architectural choice as a comparable line item on a feature matrix is how companies end up on the wrong side of it without ever having ...

Standardization means using a software platform's built-in, out-of-the-box processes; customization means changing the software itself to match your specific way of working. For most businesses, standardization combined with flexible configuration delivers lower cost, easier upgrades, and better scalability than heavy customization, which offers a precise fit but creates ongoing complexity and long-term expense. That's the short answer to the standardization vs customization software question. The rest of this guide breaks down the real differences, the often-overlooked distinction between customization and configuration, the pros and cons of each approach, and how to decide which is right for you. In This Guide You'll Learn The difference between standardization, configuration, and customization Which approach costs less over time The pros and cons of each When customization actually makes sense Why standardization supports automation and AI A simple framework for choosing the right ...

"Single source of truth" is one of the most appealing phrases in enterprise software, because it names something every leader genuinely wants: one place to look, one number everyone trusts, an end to the meeting where two teams present different figures for the same thing and spend the first twenty minutes arguing about whose spreadsheet is right. Vendors know this, which is why the phrase appears in nearly every pitch, attached to nearly every platform, as though it were a feature you could purchase and install. It is not a feature. It is a discipline, and the distinction is the reason so many organizations buy the platform, complete the implementation, and still sit in that same meeting a year later, now with an expensive system and two teams still presenting different numbers. The technology was never the hard part. The hard part is a human agreement that the technology cannot make for you, and mistaking one for the other is why these projects fail at the rate they do. They fail, ...

You know the one. It might be the allocation workbook, the distribution waterfall, the owner statement reconciliation that pulls three exports together, or the model that turns your reported numbers into the version the lender sees. It has a single author, a filename with a version suffix that stopped meaning anything years ago, and a set of formulas that only one person fully understands. And a number that appears in your financial statements passes through it every month. Most organizations regard this as a minor embarrassment, a sign that people are not using the system properly, and periodically resolve to eliminate it. That reaction throws away the most useful information the spreadsheet contains. Its existence is not a failure of discipline. It is precise evidence about your systems, generated by someone who was trying to get their job done, and almost nobody reads it that way. The risk is measured, not anecdotal Before the reframe, the risk deserves to be stated properly, ...

Your property company's AI pilot went beautifully. The demo was clean, the output was impressive, the room was sold, and the budget for the next phase got approved. That is precisely the outcome you should be most suspicious of, and the reason is not cynicism. It is that a pilot engineered to succeed cannot tell you whether the thing actually works, and most pilots are engineered to succeed. The polished demo that convinces everyone is, more often than not, the least informative result a pilot can produce. This is one of the most expensive misunderstandings in enterprise AI right now, and the numbers around it are stark. IDC research found that 88% of AI proofs of concept never reach production, with only four of every thirty-three graduating to real deployment, and MIT's 2025 work found that roughly 95% of generative AI pilots delivered no measurable impact at scale. The striking part is what these failures have in common: the pilots usually worked. They demonstrated value in the ...

Replatforming decisions almost always get made at the worst possible moment, and there is a structural reason why. For a property company, the conversation about replacing a core system rarely starts because someone calmly concluded, in a quiet quarter, that the time had come. It starts because the pain got loud. A bad month-end close, a failed audit, an acquisition the current system could not absorb, a reporting breakdown that made the limitations undeniable in front of a lender or an owner. The pain reaches a threshold, the organization decides it has had enough, and the mandate comes down: fix this, now. That trigger feels like decisiveness. It is actually a trap, because the moment the pain peaks is, with remarkable reliability, the moment your organization is least equipped to execute the fix well. The conditions that make a replatform succeed and the conditions that make the pain unbearable tend to occur in opposite phases. So "now, because it hurts now" is not the responsible ...

"Good enough" is used as an insult. Say a property system is good enough and it sounds like a shrug, a settling, an admission that you gave up before you got it right. In most enterprise technology conversations, the phrase is something you defend against, not something you aspire to. Nobody puts "we run a good enough system" on a slide to the board. They put "best in class." This is a costly confusion, because in the disciplines that have studied the question most carefully, "good enough" is not the lazy answer. It is the rigorous one. The pursuit of the perfect system, the endlessly customized, fully optimized, every-edge-case-handled ideal, is one of the most reliable ways to waste money, time, and organizational energy on technology, and what sinks most enterprise software projects isn't a lack of ambition: it's too much of it. For a property operator deciding whether the platform running the portfolio needs to be replaced or merely left alone, learning when good enough is ...