Real estate is an attractive market for software developers. There are tons of agents so there is a potential volume play for companies who make money selling lots and lots of low-margin stuff. And there are lots of real estate practitioners focused on high-touch service, which creates room for low-volume, high-margin stuff.
And if you don’t look very hard, real estate looks like the sort of industry where you solve a problem once and then roll it out nationally. A house is a house is a house, right? And a homebuyer or seller has the same set of goals everywhere, right?
These factors — lots of potential customers and a market that can scale — make real estate seem like a great industry to investigate for technology challenges. If you’re looking to make it big doing technology for real estate, here are a few things to keep in mind:
1. Don’t shortchange your UI (user interface)
There are a lot of problems in the practice of real estate that could be made easier via technology. There are communication problems, document management problems, media asset problems — all sorts of stuff.
But if the user interface of your technological solution doesn’t make the process your software is codifying crystal clear, then you aren’t solving a problem. You’re creating a new problem.
Real estate practitioners, or at least many that I’ve spoken with in the past few years, are quick to blame themselves when their technology isn’t working right. They’ll say things like, "The real estate industry is so far behind, technologically." And frankly, that isn’t true.
What’s behind is the real estate technology industry. There are too many bits of software out there that are overly complicated to use, with lots of buttons and screens and so on.
Remember that the real estate industry exists to help people who want to buy property meet other people who want to sell property, then come to an agreement about the transaction.
If your software doesn’t clearly point the way through this process in a way that increases accuracy and speed, or decreases liability, then either your software doesn’t help or your UI doesn’t help.
The tech leaders in real estate will definitely forgive a number of warts in your user interface if you’re solving a mission-critical problem in a way that truly makes their lives easier.
But you’ll never scale to the full industry if the UI doesn’t make it super simple and straightforward for everyone.
And for what it’s worth, real estate practitioners don’t need good UI because they aren’t smart enough to "figure it out or read the manual."
They need good UI because they have an exceptionally limited amount of time. And the more successful they are (i.e., the more money they have to spend on your solution) the less time they have to read manuals or user group forums.
If you don’t make the UI function well then you’re giving up the large market that might have attracted you to the real estate industry in the first place.
2. Don’t underestimate the policy challenges
As a technologist, when I first started trying to wrap my head around real estate challenges one of the biggest mind-benders was how simple most of the product-related challenges seemed.
I was amazed at the lack of standardized software for deploying solid, usable websites, for example.
And then I encountered the multiple listing service system. Suddenly, a single piece of property must be described 800 different ways, depending on localized geographic borders determined through an organic, ad hoc process that began in the 1800s.
Then, layer on top of that the various levels of visibility permissions — field by field — of each of those descriptions.
If you’re building a solution to one of the most pervasive and core challenges in the industry today — property data — then be prepared to recognize that the problem is not primarily technological.
A college kid with a copy of FileMaker could cook up a nice front-end to a SQL (pronounced SEE-kwell, for "structured query language," a computer language designed for managing databases) that would solve the technology part of property description. The challenge is policy.
If you’re going to be solving technology problems for real estate, be ready to understand the existing system (and doing so without going crazy is its own challenge). Be ready to understand how and who the existing system profits. And be ready to figure out your strategy for success in that environment.
Upon the rocks of policy many great tech ideas have wrecked. Google, for example, gave up trying to maintain and display property listings. Let that serve as the warning.
3. Avoid customization
This one might be hard to swallow. Especially for my friends who are practicing real estate. It might be hard for you as a technologist if you believe in the myth of the customer always being right. But hear me out.
Every real estate practitioner, from agent to franchise, is more or less self-employed. This means that, so long as they achieve their definition of success they are free to use whatever process they like to manage their business.
This means that there will be a lot of personalization requests for your software. Lots of feature requests. Some of the features requested by some will be at odds with policy requirements of others. The temptation to fork your code for particularly large clients will be great — leading you to increase your code maintenance costs.
I’m not saying you should ignore feature requests or discount the idea of creating fully custom code for someone. But if you do, be very, very clear whether you’re building a product that can scale, or whether you are performing a service and building customized code that your customer, the real estate practitioner, must then support.
Every customized feature you add to your code will run the risk of breaking one of the 800 policies surrounding real estate and/or limiting the size of your potential market.
Use customization requests as opportunities to finely hone the problem set you’re trying to solve or to discover new problems that need solving.
The classic example for this line of thinking is Steve Jobs, upon his return to Apple in the late ’90s, who cut the company’s product line from well over 150 machines to four. Choosing which four is the challenge, of course.
4. Don’t forget the on-ramp
Even in a market that isn’t as robust as it was five years ago, new people do take up the real estate profession. And every day, some real estate practitioner wakes up and says, "Hey, I need to get this technology thing solved."
These people are not the leaders in the industry. They’re either still learning how to do real estate or they’re just starting to get serious about using their computer (much less their mobile devices).
Oddly enough, I think this is the biggest opportunity for tech developers. Both of these groups have yet to develop real estate technology habits that you’ll need to displace if you’re making a new solution.
The group that has been in real estate for some time has the potential to offer you insights on policy and truly important features, and will be useful in helping you refine your user interface. Of course, this group also has the potential to lead you astray on personal customizations.
The group that is new to real estate will be more willing to try new technologies because these practitioners haven’t spent enough time learning existing ones yet. They may also have fresh perspectives on processes that can be improved with technology.
The real estate tech newbies, if you can develop them well, have the potential to be exceptionally valuable to the real estate technology industry. But they need a clear path, uncluttered by garbage UI, that helps them navigate the sometimes confusing policies.
And if you’re looking to build technology to solve problems in the real estate industry, this is the kind of thing you’ll need to do anyway.
