Changing programming languages
I had expected that this team would be supervised by my Project Manager and fall under the agreement to go through the process of scope and discovery, and the initial development of a MVP. A meeting was set up to meet the lead manager of the new team. When we got together, it was framed that they were working in concert with my initial group, however, rather than a Ruby team, they were a PHP team.
The fact of the matter is that it really didn’t make a difference to me. It was okay with me to architect in either framework. The new team seemed knowledgeable and actually a better fit for me, as they were open to working in a more agile environment, which would allow for me to participate more closely in the development process and learn along the way. It sounded good to me.
The scope and discovery docs were presented to the new team, and it appeared that we were ready to start. We agreed on a price, the agreement was signed to bring the new team into the fold, and development was ready to begin.
As always, it started out all peachy
Like most relationships start out, everyone had great intentions and things started happening. Code was being written and the excitement was starting to build as wireframes became mocks, mocks became code, and code became an application. I might add that along the way it was still the responsibility of my first team to provide UI design to the application on top of their monthly Consulting Agreement to oversee “the” process. Remember that one?
This is a very complicated application. NuHabitat is bringing the MLS to the consumer, so we are effectively writing MLS software. No easy task. Ask Redfin. This team had to come up a learning curve with basically no documentation or guidance on best practices for our needs. One of the standouts here has been working with our local Association, who has been extremely supportive to our efforts and willing to help in any way. This is paramount, as there are many MLSs around the country that either don’t have the resources to support such an effort, or outright refuse to do so.
Another major challenge: scaling the product
As progress was being made, there were several priorities that must be kept in mind. We must be able to scale on the back end, and needed to be responsive on the front end.
Scale. In the real estate industry, the idea of scale when working with MLS data is enough to make your head spin. What many people don’t realize is there are over 900 MLSs in the country. Zillow and Trulia don’t aggregate actual MLS data from all markets. Realtor.com does have pipes to most of the MLSs, and there are only a handful of others that access a large percentage.
There are interesting efforts being made by the likes of the Spark Platform and a few others to tackle this problem and help startups like NuHabitat develop more efficiently. The bottom line is the RETS standard, which is suppose to allow for seamless integration to all MLSs who provide RETS access, is no “standard,” and aggregating data in this industry is a beast. ‘Nuff said.
And yet another challenge: responsive design
Responsive design. One word…mobile. We are not starting off as a mobile app, so in order to use our web application on mobile devices, we had better be responsive in design and optimized for mobile. We won’t have the money to create a native app, but we want people to effectively use NuHabitat on tablets and minis. I personally find it difficult to search real estate on a phone, but there are great applications that provide basic information. I like to drill down and the screen size of a phone just feels restrictive to me.
Keep these things in mind. We’ll revisit them later. Onward.
