Software development, build or buy and the questions to ask

The Codelitt team was pleased to participate in the Re:Connect webinar this past June with a panel describing some foundational concepts in digital transformation in Commercial Real Estate with our presentation entitled “Digital Diagnostics: from Symptom to Solution”

The panel discussion showcases three members of Codelitt’s leadership team speaking about the role of User Experience Research in identifying data driven pain points, the merits of off the shelf, hybrid, and custom solutions, and strategies for converting concepts from the abstract into tangible roadmaps to digital transformation.

Our second section features Vincent Hendrickx, Codelitt’s Chief Executive Officer, speaking about key factors that shape the decision making process to buy or build a software solution in the commercial real estate space. (transcript below)

Hosted by Unissu, Re:Connect is the world's largest festival of innovation in real estate. Explore 200 sessions led by global thought leaders, all with the mission to inform your innovation and transformation strategies!

Michael: I’ll now be talking with Codelitt CEO Vincent Hendrickx we’re going to have a discussion about the merits of off-the-shelf vs custom software solutions. Specifically we’ll be looking at a few questions:

So if a digital experience is needed should a company buy or build?
What things need to be considered when you’re making that decision? So more specifically
What leads us to a buy decision?
What leads us to a build decision?

Vincent, welcome.

Vincent: Thanks Michael. And thanks Vicky as always for your wonderful insights, and thanks everyone that has joined us today.

Michael: So let’s go with an assumption, let’s assume that we’ve done proper research, we’ve made Vicky happy, we’ve outlined our UX process, or rather the pain points we’ve discovered in the process, and we have a pretty good understanding of what they are. What are the next steps here?

Vincent: Yeah so I think before considering a solution to any of the pain points that have been uncovered through research, you really need to understand their cost.

What is it that you are losing because of these issues? What is it that you hope to gain by solving them? Do you lack efficiency and hope to gain quicker deal cycles? Do you feel you lack the tools your competitors have and you’re having problems attracting and retaining brokers and clients and you need to improve your product suite?

Really whatever it is, and whatever that cost is, investigate this cost, understand it, and try your best to quantify that in dollars. So really starting off understanding the value that you hope to gain from a solution will allow you to make a smarter decision and not, say, just go with the cheaper option.

Michael: So that feels kind of like a natural progression to the clarity that we were looking for in discussing UXR. But even with this insight, that doesn’t necessarily give a company a ton of confidence if they don’t have experience in the technology space to pursue a solution like that. So what should a company do if they’re not technologically oriented right now?

Vincent: Pursuing technology solutions, especially custom ones, if that is normally not core to your business, can indeed be daunting. But really you do not need to be a technology company or even have a robust kind of IT department to build your own software. There are plenty of options out there… plenty of companies you can partner with that will not only help you build the solution, but will introduce you to best practices and processes.

And this will lead not only to these solutions, but also allow your company to learn and grow from that partnership. Subtle plug here, we just happen to be one of those companies.

Of course on the other hand, just because you do have a big IT department or you do have an existing product team doesn’t necessarily mean you should build everything in-house.

Michael: Are there any additional up-front factors to consider before we actually get into the actual buy or build dilemma or discussion?

Vincent: I’d say it’s important to really understand what it is you need out of the solution you are looking for. Do not go into the decision making process with just kind of a vision or high level understanding of requirements. Create a detailed list of what you need, from a solution. Almost every feature and every goal. And of course this should include what you expect from the overall experience.

A good understanding of scope up front will make it less likely that you will be compromising for a less than adequate solution down the line.

Michael: Okay, so now we’re armed with kind of all this insight, we understand the value that we’ll gain by solving a specific problem, we can see that we have build and buy options on the table, and we’ve got a pretty defined scope. What are the most important factors when you’re weighing this buy and build decision?

Vincent: I’d say the biggest factor will always be cost. So a proper understanding of what the cost of your decision will be. This will be fairly straightforward for existing off-the-shelf platforms, as they will (or definitely should) have a clear pricing model. And then of course that’s negotiable given the size of the contract. I would just make sure to consider how that pricing will change as you scale, and over time. If you expect to see significant growth over the next few years, thus increasing the usage of the platform or application that you want to buy, that could have a significant impact on what you get charged year to year.

Cost becomes a bit more complicated with a custom build. And as much as I hate to admit it, even the best planned projects can be difficult to estimate. Here it is important to be as specific as you can in terms of scope. More detail will result in higher confidence when estimating.

So given that in mind, when you are considering a custom build, I would recommend getting more than one opinion on the estimated effort, especially if you are considering outsourcing that to another company. If you end up seeing similar estimates kind of across the board, you can be confident in the cost. If the estimates are all over the place, you probably need to go back and take a look at your scope and try to add more detail to your scope.

Definitely in any of those cases, a custom build will most likely represent a larger upfront investment. But that spend does greatly reduce itself once you’ve kind of built that core product and you switch to support mode.

Michael: Before we go too far into the custom side, can you think of any examples or scenarios, requirements where a company should make the decision to buy?

Vincent: To buy? Yeah sure. The biggest benefit of buying software is that it is ready to go. Time to value is an important factor for any business. Especially if the problem you are facing is critical to the survival of your business in the short term. In that case you’ll be more willing to compromise on an application that maybe doesn’t meet all your needs but can get it quickly. So you prioritize that. You may not have the luxury of time to build your own solution. In this case of course you’re prioritizing, kind of that, short term benefit over the long term ones though. You’ll eventually kind of switch, or wind up building your own solution anyway.

A buy decision may also be made easy because the pain points you have uncovered are not unique to your company or even your industry. If a problem is widespread, there will most likely be plenty of off-the-shelf options to choose from. As a couple examples, almost all businesses need CRM systems, accounting programs, communication tools, HR platforms, etc and there will be plenty of those to choose from.

Michael: So what about a situation where I have an existing product right? And it solves my problem 70% of the way, it’s a partial success, or even less, it’s a 50% success metric, how does that factor in?

Vincent: That or you only end up using a small % of the tool you licensed. Then really overpaying.

But as far as an off-the-shelf tool not meeting 100% of your needs. In that case, you can always go with a hybrid solution. Developing software to solve a pain point does not always mean that you have to build this multi-million dollar platform. Many tools out there now come with robust APIs and interconnectivity. So using this micro systems approach, you may be able to license some of the parts you need and build out some of the others.

At Codelitt for example, most of the custom solutions that we build internally for ourselves focus on automations and integrations, not necessarily complete applications. We still make use of the tools we buy for coding, for designing, for data input, task management, etc but we are able to make our workflows more efficient by adding on sort of custom layers or custom connections. To give kind of a more concrete example here, we deploy our code using a simple Slack command. But that obviously still relies on slack, github and other tools…. But now even a PM can deploy code right in slack. So a hybrid solution is definitely an interesting solution.

Michael: Okay, so we’ve done kind of the off-the-shelf, talking about hybrids, but let’s do the fun thing now. Let’s go all the way to the other side, talk to me about some requirements or scenarios that lead you to ‘I need to build a custom solution’

Vincent: Well, the first, and probably the most obvious scenario, is when researching the platforms that are available, you don't find one that meets all your needs. Again as tempting as it is to get set up immediately, and go with a not-so-ideal solution that, say, meets less than 70% of your needs like you were saying before, this will definitely end up costing you in the long run. That’s kind of the obvious scenario right, you just don’t see something out there that meets your needs. But that’s a little obvious.

Another factor that will lead to a buy decision really depends on the type of problem you are trying to solve. In contrast to being better off buying a solution for a widespread problem. You may be better off building a solution if the problem is unique to your company or even industry. Even if there are off-the-shelf solutions that take advantage of that niche, they may struggle to survive, especially given their small market size. You can expect solutions like CRMs, communication platforms, HR platforms, etc to be around for several years to come.

However, once those solutions become more tailored and specific, existing ones may not be around as long... Or they may be around, but they will evolve in a way that no longer meets your needs, like Vicky was saying. This all resulting in the need now for you to switch platforms from time to time. Which obviously is a great cost to any business.

Now if you build and maintain your own software, its longevity, its lifetime, is completely under your control. You can maintain it for as long as it provides value. You can migrate it to newer technologies as tech stacks modernize. You can iterate on it as your business and your users’ needs evolve.

Michael: I would think, I don’t want to speak off the cuff or anything, I would think that control is kind of the biggest asset of a custom solution. Because that longevity you’re talking about, that control there that applies to other elements of the solution as well right?

Vincent: Yeah 100%. Control, I’d say is the biggest benefit to building your own solution. With a custom build you control what you build, providing your users with only the functionality they need. Like I mentioned before, many companies only use a small percentage of the tools they license, essentially over paying for that part that you use. Plus, a lot of extra and unneeded functionality also creates clutter and confusion for your users, essentially corrupting the overall experience for them.

With a custom build you also control your data. This is especially important when dealing with multiple sources of data, including data that is proprietary to you and your company and how your company captures that. As an example, no player in the CRE space is going to be competitive if they rely only on say CoStar data and their CoStar UI.

With a custom build you also control your responsiveness. If an issue or bug arises, that ability to react to it does not depend on how important of a client you are to a vendor. Prioritization of your issues is in your own hands. As we mentioned a few times before, this is also true for how the product evolves over time. A vendor will consider all clients and try to make everyone happy with the direction they take. This roadmap is not always going to align with what your business and users need.

You can then just always acquire the company though. There’s that option too.

Michael: So we’ve talked about the control dimension of it, we’ve covered longevity functionality, data, and responsiveness. But I have to ask, everyone is talking about the User Experience right now, how does that factor into the control in a custom dev project?

Vincent: Of course, it's a big part of that as well, and again something you can control, because increasingly consumers, clients, and even employees come to expect a personalized and consistent experience when using software. Having too many tools that differ in experience and don't necessarily speak to your brand may affect the loyalty you’re looking for from your users. Not only can you augment the user experience by building your own software, and have it align to your brand and values, you’re also differentiating yourself from your competitors.