Curb Call – From Hackathon to Production App (Part 1)
It’s been a few weeks since I presented Curb Call, on stage at the Realogy / Retsly hackathon, the day before the NAR Expo in San Francisco.
For those unfamiliar with it, it’s most easily described as “Uber for real estate”, where home buyers in the field can call for agents to initiate showings, as soon as possible. It gives agents a way to monitize small windows of downtime in their day by marking themselves as “available” to receive showing requests.
I worked as a lone wolf at the hackathon and stayed awake and hacking for all but 2 hours of the 30+ hour hackathon; it was all worth it in the end. Curb Call was the 1st runner up when it was all said and done and the best part of the prize was the chance to exhibit the app in the Retsly booth. (A nice fit since the app uses the awesome Retsly API to access data).
While I thought the concept and execution was cool, I couldn’t be sure if the rest of the industry would share my opinion. After all, I had some serious sleep deprivation going on!
I received two pretty full days of validation on that expo floor. The app was a certified hit.
Now comes the fun part…
While the app was slick, cool and functional to demo at the hackathon, it was a long way from being a fully functional app, ready for prime time use and abuse. On my short flight home to San Diego, I plotted the course for the future of Curb Call.
I am a programmer by trade and own a dev shop called Hoverboard Labs, in San Diego, CA. We code for our clients but an original goal for Hoverboard Labs was to also offer products of our own. I previously had a real estate tech startup called Robot Workshop, that was acquired in 2012, so I have some experience supporting apps in this industry.
I’m lucky to have a great team behind me so we haven’t missed a beat for our clients while I’ve been spending lots of time building out the rest of Curb Call. That includes some seriously late nights and weekends, frantically wearing out my keyboard. Luckily my wife is pretty used to these occasional coding bursts and has been amazingly supportive throughout each of them.
Where we are now
The release version of Curb Call will be more robust than the version I demoed in November. That means some major engineering challenges.
We’ve focused on reducing the number of steps needed to make and accept a Curb Call and also on making the backend (API) of the app, fast and bulletproof.
While we’re coding, I’ve had a few demos and sales calls during the weekdays. We’re talking to MLS’s, brokerages and agents about working together in the coming weeks on deploying Curb Call within their respective organizations. One of the best parts of these calls is the feedback we get from agents and brokerages on the ground. There are some great angles to be heard and we’ve integrated lots of them into the production version of Curb Call.
What comes next
First things first: we’re about to start the testing phase of development – the last step in the process. That, alone, is already really exciting.
We have to finish working on the public-facing website too.
The next thing we’ll be doing is communicating with brokerages and MLS’s that have expressed interest in being a part of the beta launch group. We’ll take the first step in deployment by launching in a handful of markets with beta partners before opening the floodgates, nation-wide.
I’ll be writing a follow-up or two with a look into the next part of the process. But first things first. It’s Sunday and I’ve got a date with an ocean of code!
Drew Meyers
Posted at 21:44h, 01 DecemberNot sure if it’s just me, but I’d love the geeky version of how this app works. What is the backend? Where is it hosted? What specific parts is it pulling from the retsly api? etc
Seth Siegler
Posted at 22:33h, 01 DecemberThough it may be hidden down here in the comments, I can give you a few details of the geeky bits:
There are two versions of the app: an agent version and a buyer/renter version. They connect to a ruby on rails backend which synchronizes certain data and communication between them, handles user authentication, etc. It’s running on the Heroku platform which uses AWS hardware.
The app pulls listing data from the Retsly API, which makes life quite a bit easier than having to deal with each individual RETS server, syncing scripts, geocoding, etc. So any MLS data we use, passes through Retsly first.
I actually made the sleep deprived decision at the hackathon to use a homemade, custom rails backend and API for the app to communicate with it instead of Parse, the backend as a service, now owned by Facebook. Parse would’ve been juuuuuust fine for the hackathon and I likely could’ve gone home for a real amount of sleep if I had gone that route but I knew that we’d outgrow Parse as a backend quickly after going live (obviously well after the hackathon). So I decided to actually start thinking about real life scale, even during the hackathon build. Glad about it now, but I’m not sure why I gave myself so much extra work at the hackathon!
Drew Meyers
Posted at 22:45h, 01 DecemberCould the frontend be easily hooked to Spark for listing data? http://www.sparkplatform.com/ (if a brokerage/MLS not supported by retsly wanted it)
Seth Siegler
Posted at 22:52h, 01 DecemberSure, that would be possible, though Spark uses oauth2 for authentication so it would have to go through the backend, which isn’t too bad.
Or we could just go straight to the rets server if it’s a non-spark, non-retsly system.
That’s just not as fun as using Retsly 🙂
Sam DeBord, SeattleHome.com
Posted at 11:19h, 02 DecemberThanks for the follow-up, Seth, very cool. I’ve certainly brought up some potential criticism, but hearing this product make its way from a hack to a marketable tool will be exciting to watch. Good luck.
Seth Siegler
Posted at 14:27h, 02 DecemberThanks Sam, I appreciate it!