The earliest days of a startup
As a startup, one of the first questions to ask is how you can put your idea in motion? I am not an application developer and I don’t know how to code. I am, however, constantly poring over startup blogs which share a consistent theme: many startup founders are programmers themselves. This can be a little deflating. Mistakes are inevitable as a startup, so I thought I would share a less than desirable experience as it relates to outsourcing your code to a development team.
NuHabitat, the company I founded, started from the need to create greater transparency with real estate data for the consumer. After all, I live in a non-disclosure state, making access to data more restrictive. In order to accomplish the goal of creating an application to provide this data, I would obviously need a code team.
Outsourcing development, building the team
My initial approach was to outsource my development. I live in Houston, and you would think there are many great companies to help a startup articulate, nurture, and develop a web application. I didn’t find that to be the case and was forced to look elsewhere. I considered a team in Austin. I also flew to San Francisco and met with a group there.
While these are hubs for software development, there was something appealing about a local team that I could meet with in person. I continued looking, and also realized I would have to increase my budget just to get a minimum viable product (MVP) out the door in Houston.
After interviewing several local companies, I selected one that I thought would be a team player. They had “the” process.
First up is the discovery process
It would cost me $12,500 to get started. We would first conduct “discovery.” This would clearly articulate my idea, flesh out the consumer experience and help to organize the process going forward. At the conclusion, I would be left with a tangible set of deliverables that I could take anywhere and effectively have a team code the application based on my documentation, however, in my case, I would need to take the finished deliverable and immediately raise money. This would prevent me from going straight to development. All parties were aware of the arrangement.
Within a week after completion of our discovery process, I was being asked if I was ready to start to the tune of $80,000 to reach a first milestone and MVP. Trying to raise money for a startup idea is not an easy proposition and certainly not in a week’s time.
After several weeks, I realized no one would make an investment in just an idea, so I would need to put up the amount needed to get started. It made sense to get something going and for me to have skin in the game to attract others.
Major hiccup: they are suddenly too busy
Unfortunately, when the time came to get started, my outsource team said they weren’t available to start developing my project. That was a shock. I had been waiting for over a month to now be set back again. I was quite disappointed, as I had been in communication with my project manager and didn’t understand the situation. The explanation was they had become too busy, but they were going to make this right.
In order to do so, they would be working in partnership with another group of developers they were bringing in to help with my project, as well as others, since they were not able to start as a miscalculation of time. It sounded good in theory.
Continue reading:
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.
And the cracks begin to show
Progress was being made, but several cracks began to appear in the foundation. Two months had passed, and I was seeing results but things were starting to slow. Communication was beginning to wane. There was no need to sound any alarms, because I had been conditioned to expect at least twice the development time and twice the expense as originally agreed. And I was seeing progress. Just not as fast I would like.
We are now approaching a usable application, and from the advice I have read over the years, you need to launch your site. You can debug forever. Get it out there. So we did. That was a bit of a crowning moment.
There were a lot of bugs, but we were launched. The response was exciting. We had great local coverage and everyone understood we were brand new on the scene, and frankly most were excited for our application regardless of any bugs. That’s what beta means!
Got the product out, but development slowed
There was still plenty to do. It was time to layout the next milestone and circle up all the bugs in V.1. We used a tracking software to collaborate on bugs. Jira was starting to fill, as was Google Analytics. We had done no real marketing or advertising for the launch. It was intended to be little fanfare with only a soft mention on social media and an email blast to early registrants.
As traffic steadied over the first few weeks, progress on the development did not. I was noticing slower bug fixes, less communication, and the carrot was being dangled with over promising and under delivering. Then came the money issue. You didn’t think this story would end without one of those, did you?
It was the standard agreement, 50% up front, and 50% at the time of delivery. We were live, but the first deliverable still had a lot of bugs. We were working on those, but also moving forward to milestone two. The money to pay the team of four had been exhausted for milestone one.
Even though the bugs had not all been flushed out, additional payments would be needed to continue so a cost associated to finishing milestone two was agreed upon, and 50% was forwarded to the team. Meanwhile, the second payment for milestone one was withheld. Of course I recognize the accounting zero sum game, but it kept the intention straight. Correct the bugs and get more money.
Work proceeded, but it became apparent that certain feature sets that were labeled as “no problem”, were in fact, becoming a problem. Things that should have been easily integrated were now taking long periods of time. The cracks were getting larger.
“They have mastered the art of dangling the carrot”
Now it’s time to take a step back and look at what’s really happening. This is where things get incredibly tough, because you have invested a tremendous amount of time working with a team, articulating your idea and your vision. Going over user UX and UI for hours and hours. You want to trust the guys you have dropped a large amount of cash on and that have taken you this far. After all, we were live.
On the other hand, they have mastered the art of dangling the carrot just right to take advantage of your excitement and passion for your startup. They know just how to string you along with the promise of the next deliverable and telling you it will be fixed tomorrow, but nothing happens. They need more money, so right at the time you want to throw in the towel and move on to a new team, they drop some code on you and the whole cycle starts over.
Now you are limping along, holding on on to the dream that these guys actually care about your application when it has become painfully obvious that you are no longer their priority. You feel like a battered wife who keeps coming back for more but the idea of transitioning your entire development environment to a new team and bringing them up to speed is overwhelming. This is actually the best case scenario, which I was lucky to find myself in. It could be far worse.
Time to cut the cord, take the loss
I had control of my environment. My code was on GitHub. I was hosted on AWS and my domain was purchased in my name. These might seem obvious to some of you but to a new entrepreneur, these could be critical mistakes.
Imagine if you didn’t own your domain in your own name, your code was in a version control system you did not have access to, and your hosting was in an account owned and managed by the team from which you are trying to separate yourself. This alone could be the demise of your startup.
The time had come. These guys had disengaged. Nothing was being delivered. They were ahead of me on contractual payments. Communication was at a minimum and if their lips were moving, they were lying. Their new interest seemed to be in gaming.
Pivoting, building in-house team
The good news. I had two engineers that were getting the same treatment. They had almost no communication from the lead engineer, and they weren’t getting paid. Fortunately, they did believe in the application. As with most engineers, I have been told it is less about the money than what is being created. I was able to keep these two guys on board. Along the way, I struck a relationship with an architect who was experienced in exactly our stack. I was able to bring him on board as we were faced with a serious migration. Additionally, I had engaged an individual specifically tasked with terminating my previous relationship in terms of code and access and helping to make sure we had a seamless transition and the site remained stable.
At this point, there were questions to be asked. How good is the code? Will it run on its own? Does it have integrity? What am I left with?
Once these questions were answered it was time to start cleaning up the mess. I consider myself lucky. I had some very knowledgeable engineers that were able to identify the shortcomings, create a plan of action and start architecting things the way they should have been done in the first place. I mentioned earlier the need for scale and responsive design. These were two of the missing elements. While the application is engineered in a way to accommodate my local MLS, it wasn’t architected to scale. And while the application ran fine on a desktop web browser, it didn’t on mobile devices. That has since been rewritten and now displays beautifully on phones and tablets.
Back in the saddle again
So here we are. We are over the hump and great progress is being made once again. I am no longer working with someone else’s team. I am now working with my own. I am grateful for the engineers who believe in the mission. We collaborate daily and working with them is a pleasure. We are tidying up a few loose ends and will once again be moving forward to new features that should start to establish our brand as an innovator in the real estate technology space.
Lesson learned. Be insanely diligent in scrubbing the outsource team you hire to build your company and make sure you are in control at all times OR hire your own team.