Rails For All

is an Internet marketplace that seeks to apply the same techniques that other industries have to use the Internet to bring people together. The people are not buyers and sellers, but donors and nonprofits. Our advisors include the heads of the Lance Armstrong foundation, Save the Children, First Book, Sierra Club and many others. We feature some 200 nonprofits, and users can donate to any nonprofit that has filed a US tax return in the last 5 years.

In the early stages, we considered Java for scalability and stability, but the early bids came back and the project looked too expensive and complex. We settled on Ruby on Rails because it gave us the best combination of great productivity, a clean programming model, and reasonable performance. Still, the decision was not without concern. Based on existing portals and our business plan, we decided that we should be able to handle hits in the millions, daily. Though few Ruby sites have such high traffic requirements, we thought we could provide that kind of scalability through aggressive caching and simple shared-nothing clustering, though we couldn’t find any evidence of such sites at that time.

Through the early months, we were extremely productive, showing significant progress with each weekly demo, and the management team noticed. In November, we fully committed to Rails. Shortly thereafter, we released the first beta version of the site. Our team built the initial version of the site at about one fifth of the projected cost of bids using other languages, and in about one sixth of the projected time. Rails has absolutely been critical to our productivity and success.

We’re far from finished with the site-we’ve built roughly five percent of what we’ve planned-but we have a good enough foundation to begin to execute the next steps of our business plan. Though we’ve done some minor benchmarking and profiling to give us some assurance that we’ll be able to handle the big loads when the time comes, we can’t be sure that our current deployment will be able to handle the massive volumes we’ve projected for the long term, because few Rails sites ever have. But we’ve got high confidence that:

• We can build features, test them well, and deploy them quickly
• We will be able to scale to high volumes with minimal hardware
• We can add additional hardware transparently as our needs grow
• Our team of five developers can both develop and manage the site through the early growth curve
• We can solve any additional scalability and performance problems that come up

From the above list, the most important item for us is productivity. The team must be productive enough to satisfy our management, customers and investors, while staying ahead of our competition.