We started working on crowdSPRING in the summer of 2006. We incorporated the company in May 2007 and launched the crowdSPRING marketplace in May 2008. We’ve learned many important lessons along the way. In some ways, our experience is typical of other start-ups. In other ways, it is not. I want to share some of our adventures (and mis-adventures) in the hope that it’ll help others looking to start a company or those who’ve already launched a start-up.
Yesterday was the one year anniversary from the time we launched crowdspring.com publicly. We shared in this post why we skipped the celebration yesterday.
Some who received our email have written asking us to share more details about the problems we’ve had over the past 10 days with the site and what we’ve learned in the process.
A Little Background
We built our application (starting in mid 2007) using PHP and eZ Publish. Before launch, we spent 9 weeks in a closed beta, thoroughly testing our hardware and software architecture. When we launched into our closed beta on March 6, 2008, our dev team concluded that our application would have difficulty fully scaling as traffic and registrations to our site increased. We suspected before our closed beta that this could be an issue, and were extremely disappointed when our suspicions became true. Our dev team then did something that continues to amaze us to this day. Before we launched publicly a mere 8 weeks later, our dev team rewrote nearly all of the code for the site and made numerous hardware architecture changes. It was a brutal period for our entire team. Many 20 hour days (especially for Chad), numerous all-nighters, and tons of problems.
When we officially launched in May of 2008, we were much better prepared to handle the traffic, but we remained concerned about our ability to fully scale. Within weeks after launch, we made significant hardware upgrades to our database server, anticipating much higher traffic as a result of our successful appearance at the Under The Radar Conference in California. We made additional hardware upgrades throughout the summer as we continued to gain visibility from some outstanding news coverage and continued attention. However, we realized mid-summer that hardware improvements alone would not allow us to fully and flexibly scale. The underlying problems were the result of the way our application was written and the structure of the content management system (CMS) that we were using. It’s an outstanding CMS, but for our application, it did not scale particularly well. Throughout the summer, we worked with one of the core developers of that CMS to find ways to address our concerns about scaling, but ultimately, we concluded that long-term, we would need to re-architect our application and start from scratch.
The Refactoring Process
We spent several months evaluating and researching various options, including .NET, Ruby on Rails, PHP, Python, and Java. All had various advantages and disadvantages. After much thought and debate, we elected to refactor our entire code base using Python and Django. We recognized that with a small dev team (3 people), we would face some significant challenges because we would need to concurrently work on the refactoring project and support our production site. As our former president George W. Bush used to say, we mis-underestimated those challenges.
(more…)
