At the heart of Houwzer’s operations is its technological solutions. The Houwzer platform keeps client data secure, allows operations to scale, while also delivering a user experience that is simple, intuitive, and personalized.
Although it may look and feel seamless to the user, this requires a flexible and resilient application programming interface (API). Developing this API required building a protocol with the needs of a real estate company at the forefront of design.
The Briefings Direct podcast is an enterprise IT podcast that explores software infrastructure topics through interviews and analysis. Houwzer’s CTO Greg Phillips was recently asked by Podcast moderator Dana Gardner to delve into the site’s unique architecture and what it means for the future of real estate.
Below are some excerpts from the chat. The full transcript can be found on BriefingsDirect, or listen to the episode via Apple podcasts.
Gardner:
Greg, what does Houwzer do, and why is an API-intensive architecture core to your platform?
Phillips:
We are more than just a real estate brokerage. We’re also a mortgage brokerage and a title agency. The secret sauce for that is our technology platform, which binds those services together and creates a seamless, end-to-end experience for our consumers, whether they are buying or selling a home.
Those services are typically fragmented among different companies, which can lead to an often-chaotic transaction. We streamline all of that into a much smoother experience with our salaried agents and a consistent technology platform across the whole transaction. We are rethinking how real estate transactions are done by making it a better experience across the board, inclusive of all those services.
Early on, we decided to build, essentially, a protocol for conducting real estate transactions. There are laws and regulations for how to conduct such transactions in different jurisdictions. Instead of having an unmanageable variety of local rules and regulations — in one area they’re doing it one way, and in another area doing it another way – we looked for the common elements for doing real estate transactions, mortgages, and for titles.
We’ve built into our system these common elements around real estate transactions. From there, we can localize to the local jurisdictions to provide the end services. But we still have a consistent experience across the country in terms of offering services.
That’s why we began with an API-first architecture. We focused on the protocols and building-blocks of the platform that we offered to our agents, coordinators, and mortgage advisers for their services. Then we layered on the front end, which has a lot more localization and other services. So, we very intentionally thought about it as a protocol for conducting real estate transactions, rather than building an app to manage just specific types of real estate transactions in specific jurisdictions.
Gardner:
When say API-first, what do you mean? Was that how you constructed your internal platform? How you deliver the services? Was it also for the third-party and internal integration points? All of the above?
Phillips:
All of the above, yes. We wanted to build an API core that was flexible enough to support lots of variants within different types of real estate transactions. We’re already in seven states. And we’re still pretty early in our journey. We’re going to be adding more states and jurisdictions.
So, we knew from the get-go that was our direction. We put a lot of thought into our data model and our API platform, such that we wouldn’t have to rewrite or break up the APIs every time we entered a new jurisdiction. We wanted a flexible underlying API that we could use to offer a finished product, even though it might look a bit different in Maryland than it does in Pennsylvania, for example.
We wanted to build an API core that was flexible enough to support lots of variants within different types of real estate transactions. … We put a lot of thought into our data model and our API platform.
Gardner:
It’s evident that such flexibility, speed of development, and reuse of services are some of the good things about APIs. But are there any downsides? What can detract from that versatility when going API-first?
Phillips:
One of the downsides of APIs is once you put it out there into the world, you are supporting that API, for better or worse. Things get built against it. And if you want to change or rethink what you do with that API, you have downstream dependencies reliant on that API.
It’s not like you’re a single code base, where if you want to refactor, you can use your idea to go discover all the things that might break if you change things. With the API model, it’s harder to know exactly who’s out there using it, or what might break if you change the API.
From the very beginning, we’ve been really concerned with security. Even before we had any transactions running through the system — and we were just in the design phases of the API — we knew we’re in an industry that’s constantly under attack.
The most common and dangerous thing that happens in the real estate brokerage industry is when some non-public information about a transaction is somehow leaked. There are a lot of criminals out there who can use that information to attempt to exploit our customers. For example, if they find out information about when a closing is supposed to be in the name of the title company, they could pose as an agent of that title company and say, “Hey, for your upcoming closing, the wiring instructions have changed. You actually need to wire ‘here’ instead of ‘there’.”
We’ve seen brokerages across the country fall victim to that consistently over the past five to 10 years, if not longer. It’s been a huge problem in the industry. So, while an API enables a great user experience by having very streamlined transactions, we need to make sure that the information stays private to only our clients, agents, and coordinators — and not leak any of that data to the public through the API. That’s been paramount for us… (listen to the full podcast here).