With the digital mortgage revolution underway, the discussion around taking on new technology is as much about where it’ll come from as which initiatives to pursue.
Mortgage lenders are being forced to evaluate whether or not buying or building a product is the most effective way to go after a year of higher rates that constrained their profits, and business conditions that just recently have begun to improve as those rates have come down.
Buying a product is typically the quicker and most cost-effective option in the short run, as a tool is already in place for institutions to evaluate, and it’ll be more readily available for integration. But companies developing their own technology, though a hefty and potentially expensive task, have the advantage of customization, and may wind up spending less money down the line.
But given the complexity of the mortgage business, no tool is truly “off the shelf.” Institutions must ensure that a product can integrate within its existing suite and configure it to meet specific needs, which can require additional expenditures.
So when considering a product to purchase, mortgage companies may want to have a comprehensive checklist to ensure the product they’re purchasing fulfills its purpose.
“The sales pitch and the sex and sizzle are the things people usually get excited about when you’re looking at a new product. I think it’s important when you go through the vendor discussion and the vendor review, that you have a checklist of things you’re looking for — whether it’s requirements or feature function capability — and you’re able to score it,” said Bob Orkis, principal at RKO Technical Services.
Orkis was among panelists at the Mortgage Bankers Association Technology Conference in Dallas who weighed in on this topic on Monday.
Should a product check the desired boxes, having a proof of concept is crucial to ensuring it measures up. This way, mortgage companies can assess how and if a tool is applicable to business-specific use cases. In testing, “dummy data,” can be used to avoid drumming up privacy concerns.
Some vendors do charge for a proof of concept, but a smaller upfront cost is better than millions wasted post-contract, said Orkis.
And while costs to buy overall seem cheaper than building a tool into existence, expenses stack up annually and typically increase with time.
“When you’re looking at what the cost is, don’t just look at one to two years, look at it at maybe five years and see what that picture looks like,” said Suzy Bashore, chief information officer at PGIM Real Estate Finance.
Developing a tool means it’ll be constructed to handle a company’s mortgage volume and will integrate with other pre-existing technologies. But opting to build also opens a different can of worms as companies navigate time, resources, manpower and regulations.
Some companies may choose to first develop a fully comprehensive tool before launching it, which may take longer but has fewer kinks. Others instead will roll out something more quickly and learn as they go. But both approaches have their flaws.
“’Fail quickly and iterate’ works really well for development teams. It doesn’t work so well for the people who are using it on the front-end, and are frustrated when it doesn’t work and you tell them that ‘our next sprint is going to fix that so just wait a week,’” said Aaron Perlis, executive vice president and chief technology officer at Walker & Dunlop.
“But the ‘big bang’ process doesn’t work either,” he said. “It’s about, ‘how long is it going to take me to build, cause if I go away, build this new system for 12 months and come back and it’s just kind-of cool, that’s almost worse than going through an implementation of something that’s bought.’”
But whether built or bought, staying mindful of business objectives sits at the core of tech implementation, requiring heavy attention from business leaders and stakeholders over a tech department.
