Property Management Systems (PMS) and property operations software have imperceptibly become a necessity, the heart of the multifamily business ecosystem. Every property owner, from small to boutique, corporation to multinational, will eventually come across this conundrum: to build or buy their operations platform, at least once in their career. While it’s true that some larger multifamily ownership groups and property management companies have developed their own proprietary PMS or property operations software in house, it’s definitely the exception, not the rule. Here are the things to consider before deciding to build your own property management platform or operations software.
What’s Your Core Competency?
Software development is a specialized skill. Do you have those development skills in-house? Most property management companies do not. If you’re among the few that does have in-house developers, ask your engineers for feedback on their experience with the problem and how they’ve dealt with it in the past. Find out what tools they’ve used or in what other creative ways they’ve solved the issue – and then consider their experience heavily when making your decision.
A good product development rule of thumb when evaluating build vs. buy decisions is:
• BUILD to your distinctive competencies
• BUY basic technologies
• PARTNER for the rest
Since a PMS or fully featured operations platform is anything but a basic technology, the question is: what are your distinctive competencies? If you answer anything but “software development,” consider buying or partnering with a specialist multifamily vendor.
What’s Your Timeline?
The time and effort needed to maintain in-house built solutions are, oftentimes, vastly underestimated. Not only do you have to build and maintain the code, but you also have to manage the infrastructure needed to serve that code. What looks like a one engineer job could easily turn into three or four engineers with different skill sets needed to work across the stack.
It’s easy to find that the project takes more time and money than anticipated. Even for seasoned software development teams, it can take many false starts before arriving on a robust or winning solution or feature. At a minimum, you should budget two years to get to a workable solution.
What’s Your Support Plan?
It’s easy to forget about this aspect of software development, because the build is the easy part, believe it or not. Once the software is ready, it’s time to test it, install it, train your internal users on it, and then support it as new enhancements are required to support your goals. A key consideration here is the IT infrastructure within which your software will co-exist
The downside to a homegrown PMS or operations platform is that the work is never done, because your team will need to focus on developing constantly to keep up with feature enhancements and bug fixes. As an example, if Amazon Web Services goes down and you’ve relied upon that technology for hosting your data, your internal support team will need to develop triage, escalation, and service level agreements or support protocols to ensure consistent operations across your portfolio. It’s not uncommon for integrations and APIs to break whenever co-existing systems are updated or upgraded.
Is Your Culture Prepared to Train and Nurture Talent? Are You Sure?
The “great resignation” has affected nearly every sector of the American economy. Engineers and technology experts have more opportunities than ever, and they require a different management style than maintenance technicians and property management staff. Make sure to ask yourself: is your culture set up to attract, nurture, and retain these specialized employees?
Adding on a new project to your IT team that not only needs to be maintained, but built from the ground up with thorough documentation can be damaging if you don’t have the right team. If key members of the team end up leaving the company, you could lose critical corporate memory, making it costly and time-consuming to make changes down the road. Your project plan could potentially be set back by weeks or months.
Build vs. buy remains a discussion for every organization to have. Every circumstance is different and there is no single answer that is the best for everyone. Organizations must do the analysis for themselves. However, if buying a solution is relatively straightforward, has no real obstacles, and solves the problem adequately, then it is usually the right choice.
