Just as interesting to me as the tech stack is the business stack. There have to be some really tightly-managed pipelines of deals because Opendoor is fronting capital to buy up the houses. Interesting scaling challenges there on the capital side.
If Opendoor works out how to quickly vacate the newly-bought property, then automate much of the project coordination activity that is done to flip the property by automatically scheduling and bringing in contractors and inspectors, that could lead to some really interesting returns. Even if the sprucing up is not to flip for huge amounts, just the usual repairs and freshening changes, combined with an empty house to show, could easily lead to semi-automation of a buy-low sell-high, high-volume business of conveniently buying a lived-in house, and selling a nice-looking, nice-smelling, high-curb-appeal house for much higher than the original property owners could bring. Automate the scheduling of staging and unstaging, and goose the numbers even more. I can see all sorts of other follow-on monetization streams from this simple change in the process you guys introduced, thanks for the thought-provoking write up, I look forward to reading much more about your successes in the future.
But it basically is flipping isn't it? Maybe they can work out how to flip a little cheaper with technology but this model only works because flipping is so hot right now.
Very true on the financing, and how it connects to our business. There have been plenty of companies in the past whose business model is to buy distressed houses and flip them; Opendoor is coming from a very different angle. We'd like to buy and sell houses at normal prices, do a lot more volume, and make smaller margins on each transaction than the traditional "flipping" business.
Because of that model, it's very important that we (1) have access to a lot of capital, and (2) renovate and resell the property quickly, so we can put the money to use again.
the business model is fascinating. the capital requirements make opendoor seem crazy on the surface, but it is not at all insane if you dig deeper.
the short term model is predicated on managing inventory like a retailer and diversifying holdings like a trader. mastering both functions, let alone one, is very challenging, but far from impossible. if opendoor can acquire data and predict transactions better than competitors, the mountain top becomes eminently more climbable. from a portfolio perspective, the early stages are actually the least risky because opendoor can cherrypick the best real estate markets, and within those markets, cherrypick the best homes, where "best" means the properties most likely to sell quickly and profitably.
the long term vision has not been articulated, but it seems like opendoor could grow into a platform for homes much like amazon is a platform for consumer goods. opendoor would provide the buyers, product guarantees (e.g., home inspections passed), the open house experience, and predictive analytics (e.g., home X has a 80% chance of turning over in 30 days if priced at $1M) while others manage financing and inventory risk. if this conjecture is right, look for opendoor to (a) lower prices and (b) streamline real estate transactions with automation where possible and where not possible, to empower untrained (i.e., cheap) individuals with computer vision and smart software to perform tasks like certified professionals. if neither happens, consider the conjecture wrong. :)
Thanks for the comment -- and it's very accurate in terms of where we'd like to go.
On a tangential note: empowering untrained individuals is important, but we often do the opposite too. Many of our internal tools are designed to make trained professionals/experts as efficient as possible.
I'd say the main direct effects were (1) we were able to iterate very fast on our internal tools, which are used by internal operators to manage each transaction; and (2) our data science setup has allowed us to price homes incredibly accurately. Many companies have estimates of a home's value, but Opendoor puts its money where its mouth is ;)
Can you please write an email to your Marketing Department and pass along a note?
Here's the text:
"While effective in your goal of creating Brand Recognition of 'Open Door' please be informed that the blitz campaign with the radio ad featuring the sound of a doorbell ringing, followed by the company name, 'Open Door,' was one of the most unabashedly Pavlovian ear-worm manipulation techniques I can recall. It almost makes 'Head On - apply directly to the forehead' look like high art. DING DONG - OPEN DOOR! DING DONG - OPEN DOOR!
Because of this tactic, I will never, ever reflect upon the brand of Open Door with anything but disgust. Yeah, you got market share, good for you. How you did it, however, makes me want to puke."
It might sound extreme, but I have a sensitive brain. That goddamn commercial was everywhere. And terrible.
I like that you do code reviews of every commit, do you have any issues with getting people to spend time reviewing? Also, it looks like you have a very broad code base (backend, frontend, mobile, machine learning...), do all of your engineers review code for all of those areas? I've found that in small teams sometimes only one person really understands a particular section of code, which can result in poor quality code reviews. I'm interested to hear if you've experienced that, or if you've managed to work around it.
FYI, the title of https://www.opendoor.com is: "Opendoorflexible-dateno-repairopen-houseonline-processfair-inspectionfast-closinghome-readycustomer-supportfair-offertransparency | Sell your home the minute you're ready.", which looks like a mistake to me. Probably need to add another test ;)
It's mentioned that the "projected cost" logic outgrew Rails, but there's no mention of what that microservice eventually wound up running. I'm curious what you had success with.
I love code reviews, and the code review pipeline, but one issue I keep running into is handling a bottleneck'd review process, and I'm wondering if you have any tips or advice.
How do you stay productive while blocked on a review request?
If you stay productive by swapping to a different task, how do you avoid merge, dependency, and task switching headaches between what's under review and the "back-up" tasks?
I'm not sure if that question is clear, but I'm betting on you having encountered similar enough situations to know what I'm getting at.
We started in 2014 with a Ruby on Rails monolith and Angular frontend, both of which were good ways to move fast while we were very small. We use Webpack to build our frontend apps, and serve them using the Rails Asset Pipeline.
Within your MVP how did you handle authentication between your Angular apps and your Rails backend? I know you implemented Paladin to handle auth between your new microservices but I'm curious what auth looked like in your MVP.
What make and model door knobs do you use? I manage some rental houses and have wanted to automate showings go some time. Do you add a cellular Wi-Fi hotspot temoparily too?
What an amazing business model. Not something I would have considered as I would consider the capital requirements too high to purchase almost any house. They will walk a fine line between being too picky and excluding an average consumer or having too high a price and losing money. But regardless it is very cool and potentially disruptive, much more than Redfin. A silicon valley version of "We buy your homes for cash"
EDIT: As commentors on BiggerPockets are saying, it is just like Carmax.
As a senior computer science student, who constantly tries to learn and keep up to date on his own time, I felt a little overwhelmed after reading this article. I know that they are just tools that can be learned, but my question is about junior devs. How do you go about hiring (if it is the case that you do hire junior devs) and training them?
Ah, they're just tools that can be learned. I had to run around the company quite a bit to make sure I got all the information right.
We don't require experience in any of these tools to get a job at Opendoor. Most programming experience can be transferred between different technologies. We do a lot of pair programming to bring people on board, plus feedback in code reviews.
I wonder, if the stack would be radically different if a) interest rates increase to 'old normal', and/or b) price trend reverses in the opposite direction.
this looks quite clever, opening doors via a code? nice. that would certainly get my attention.
One thing, are you guys doing any modelling using graphs? or is all your data normalized and stored in relational DBs?
I can't speak for the data science stack, but everything in the web stack is Postgresql (with the exception of Redis for background jobs and things of that nature).
Hey! Zain from Opendoor here. We actually just switched to using Kwikset 914 locks instead of the Schlage ones. API docs are basically nonexistent for both, but the Kwikset is a lot easier to reverse-engineer than the Schlage! Feel free to email me if you have specific questions about either lock. zain@opendoor
Buying and selling over $1B in home is not impressive when done by a computer. If someone did it single handedly maybe. I hate when people quote numbers to impress and confuse others. At $100,000 that's 10,000 homes. Selling 10,000 items is not impressive. So why should I care what stack you used?
We purchase and sell the homes, including the inventory management (repairs, renovations, security, utilities), home visits, pricing & negotiation, mortgages, title & escrow... real estate is quite involved and the largest and most emotional transaction most people will make in their lives
[+] [-] yourapostasy|9 years ago|reply
If Opendoor works out how to quickly vacate the newly-bought property, then automate much of the project coordination activity that is done to flip the property by automatically scheduling and bringing in contractors and inspectors, that could lead to some really interesting returns. Even if the sprucing up is not to flip for huge amounts, just the usual repairs and freshening changes, combined with an empty house to show, could easily lead to semi-automation of a buy-low sell-high, high-volume business of conveniently buying a lived-in house, and selling a nice-looking, nice-smelling, high-curb-appeal house for much higher than the original property owners could bring. Automate the scheduling of staging and unstaging, and goose the numbers even more. I can see all sorts of other follow-on monetization streams from this simple change in the process you guys introduced, thanks for the thought-provoking write up, I look forward to reading much more about your successes in the future.
[+] [-] frgtpsswrdlame|9 years ago|reply
http://www.housingwire.com/articles/39523-home-flipping-hits...
[+] [-] azirbel|9 years ago|reply
Because of that model, it's very important that we (1) have access to a lot of capital, and (2) renovate and resell the property quickly, so we can put the money to use again.
[+] [-] panabee|9 years ago|reply
the short term model is predicated on managing inventory like a retailer and diversifying holdings like a trader. mastering both functions, let alone one, is very challenging, but far from impossible. if opendoor can acquire data and predict transactions better than competitors, the mountain top becomes eminently more climbable. from a portfolio perspective, the early stages are actually the least risky because opendoor can cherrypick the best real estate markets, and within those markets, cherrypick the best homes, where "best" means the properties most likely to sell quickly and profitably.
the long term vision has not been articulated, but it seems like opendoor could grow into a platform for homes much like amazon is a platform for consumer goods. opendoor would provide the buyers, product guarantees (e.g., home inspections passed), the open house experience, and predictive analytics (e.g., home X has a 80% chance of turning over in 30 days if priced at $1M) while others manage financing and inventory risk. if this conjecture is right, look for opendoor to (a) lower prices and (b) streamline real estate transactions with automation where possible and where not possible, to empower untrained (i.e., cheap) individuals with computer vision and smart software to perform tasks like certified professionals. if neither happens, consider the conjecture wrong. :)
[+] [-] azirbel|9 years ago|reply
On a tangential note: empowering untrained individuals is important, but we often do the opposite too. Many of our internal tools are designed to make trained professionals/experts as efficient as possible.
For more speculation on Opendoor's business and where we might take it, I think Stratechery has a good writeup. https://stratechery.com/2016/opendoor-a-startup-worth-emulat...
[+] [-] mruniverse|9 years ago|reply
Otherwise it's just a list that doesn't have much connection to the $1B part in the title.
[+] [-] azirbel|9 years ago|reply
Happy to answer any more questions about it.
[+] [-] kandalf|9 years ago|reply
[+] [-] 6stringmerc|9 years ago|reply
Here's the text:
"While effective in your goal of creating Brand Recognition of 'Open Door' please be informed that the blitz campaign with the radio ad featuring the sound of a doorbell ringing, followed by the company name, 'Open Door,' was one of the most unabashedly Pavlovian ear-worm manipulation techniques I can recall. It almost makes 'Head On - apply directly to the forehead' look like high art. DING DONG - OPEN DOOR! DING DONG - OPEN DOOR!
Because of this tactic, I will never, ever reflect upon the brand of Open Door with anything but disgust. Yeah, you got market share, good for you. How you did it, however, makes me want to puke."
It might sound extreme, but I have a sensitive brain. That goddamn commercial was everywhere. And terrible.
[+] [-] 8_hours_ago|9 years ago|reply
FYI, the title of https://www.opendoor.com is: "Opendoorflexible-dateno-repairopen-houseonline-processfair-inspectionfast-closinghome-readycustomer-supportfair-offertransparency | Sell your home the minute you're ready.", which looks like a mistake to me. Probably need to add another test ;)
[+] [-] and0|9 years ago|reply
It's mentioned that the "projected cost" logic outgrew Rails, but there's no mention of what that microservice eventually wound up running. I'm curious what you had success with.
[+] [-] RangerScience|9 years ago|reply
I love code reviews, and the code review pipeline, but one issue I keep running into is handling a bottleneck'd review process, and I'm wondering if you have any tips or advice.
How do you stay productive while blocked on a review request?
If you stay productive by swapping to a different task, how do you avoid merge, dependency, and task switching headaches between what's under review and the "back-up" tasks?
I'm not sure if that question is clear, but I'm betting on you having encountered similar enough situations to know what I'm getting at.
[+] [-] Abundnce10|9 years ago|reply
Within your MVP how did you handle authentication between your Angular apps and your Rails backend? I know you implemented Paladin to handle auth between your new microservices but I'm curious what auth looked like in your MVP.
Thanks!
[+] [-] foznic|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] hkon|9 years ago|reply
[+] [-] amalag|9 years ago|reply
EDIT: As commentors on BiggerPockets are saying, it is just like Carmax.
[+] [-] aecorredor|9 years ago|reply
[+] [-] azirbel|9 years ago|reply
We don't require experience in any of these tools to get a job at Opendoor. Most programming experience can be transferred between different technologies. We do a lot of pair programming to bring people on board, plus feedback in code reviews.
[+] [-] bradknowles|9 years ago|reply
[+] [-] zan2434|9 years ago|reply
[+] [-] rodionos|9 years ago|reply
Global housing prices: http://www.economist.com/blogs/graphicdetail/2017/03/daily-c...
[+] [-] safeharbourio|9 years ago|reply
[+] [-] cnnrjcbsn|9 years ago|reply
[+] [-] NicoJuicy|9 years ago|reply
But i'm curious for two things:
-why they use those except for the different models Schlage has.
-where is Schlage api's documentation :p
[+] [-] zain|9 years ago|reply
[+] [-] hitekker|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] segmondy|9 years ago|reply
[+] [-] jdross|9 years ago|reply
[+] [-] JohnJamesRambo|9 years ago|reply