Devver (pronounced like “developer,” not “devious”) launched in 2008 to help software developers use cloud-based services to “test” their code in a more expedient manner than current practices. The firm started by focusing on Ruby on Rails software applications.
One of its flagship products, Caliper, provided quality metrics to Ruby on Rails developers for their Ruby on Rails code. By using Caliper, a Ruby on Rails developer could quickly discover problems like code duplication, complex code, and code “smells.” In computer programming, a code smell is any symptom in the source code of a program that possibly indicates a deeper and potentially more serious problem.
Dan Mayer and Ben Brinckerhoff are Devver’s cofounders. The two met in high school and started a Web business before their high school graduations. Both studied computer programming in college, Mayer at the University of Colorado and Brinckerhoff at Washington University in St. Louis. The two reunited in 2008 to launch Devver. They are graduates of TechStars, a Boulder, Colorado-based mentorship-driven seed stage investment fund. Devver operated from early 2008 until early 2010, when it went out of business. In announcing its plans to close, the company indicated that although it had worked hard to achieve its vision—to use the cloud to build tools that would change software developers’
lives—it couldn’t generate sufficient revenue to sustain and grow the company.
In a thoughtful blog post, Ben Brinckerhoff reflected on the reasons he feels resulted in Devver’s failure. While the reasons were varied, the key reasons focused on the composition of the founding team, difficulties in communications, and product development.
In regard to the founding team, both Mayer and Brinckerhoff thought of themselves as geeks. Looking back, Brinckerhoff feels it would have been to their advantage to have had another cofounder who loved the business side of running a start-up. In reflecting on this observation, Mayer challenged the oft-repeated statement that “You can teach a hacker business, but you can’t teach a businessman how to hack.” This statement is sometimes used by technical founders to justify not needing a businessperson on the team. While Mayer acknowledges that it’s possible to teach a hacker business, you can’t force a hacker to get excited about it, or give it the proper amount of attention. According to Mayer, what hackers like to do is hack. So they measure progress in lines of code written or use a similar metric.
It’s equally important to have someone in a start-up measuring progress on business metrics—like number of customers talked to or how well distribution channels are being developed. Not enough of that happened at Devver.
In regard to communication, Devver embraced working remotely. The company started in Boulder, where the two cofounders worked together. Devver’s first key hire worked in Pennsylvania, and Mayer later moved to Washington, DC. The idea was that by embracing working remotely, Devver could hire the best talent available without requiring people to relocate to Colorado. In addition, they felt that by allowing team members to work remotely they would experience minimal distractions, which is important when it comes to effective code writing. Regrettably, achieving these objectives was more difficult than the founders anticipated. Communication was a challenge. It was also an administrative hassle. Mayer and Brinckerhoff found that it was a pain to manage payroll, benefits, and so forth in several states simultaneously. In addition, pair programming was difficult to do remotely—a challenge for which the Devver team never found a good solution.
Finally, Brinckerhoff believes Devver should have spent more time on customer development and finding a minimum viable product. A minimum viable product has just those features that allow a product to be deployed, and no more. It’s typically deployed to early adopters for testing. The idea is to avoid building bells and whistles into products that customers don’t need or want. Instead of doing this, Devver did minimal testing of its first product, the Ruby test accelerator, and then focused intently on building out the product without additional interaction with potential users. As a result, its Ruby test acceleration and additional products never really met market needs until Devver ran out of steam. In retrospect, Brinckerhoff believes Devver should have deployed individual products sooner, and solicited more customer feedback about pricing, market size, and technical challenges. Eventually, they learned that their market was too small and their price point needed to be too low to sustain the company.

Questions for Critical Thinking
1. In retrospect, Brinckerhoff believes that it would have been to Devver’s advantage to have had a businessoriented cofounder as part of Devver’s new-venture team.
Do you think the reverse is true? If two businesspeople are set to launch a technology-oriented firm, do you think it’s to their advantage to have a technology-oriented cofounder, or is it sufficient to hire technology-oriented personnel?

2. Make a list of the pluses and minuses of adopting a philosophy of allowing workers to work remotely. Is this philosophy better for some types of start-ups than others? What is your opinion of this philosophy?
3. The “You Be the VC 9.1” feature focuses on YouTern, a Web-site that matches companies looking for interns with college students interested in internship opportunities.
What do you think a minimal viable product would have looked like for YouTern? How could YouTern have used the minimal viable product methodology to get user feedback about its site before committing substantial time and resources to building it out?
4. Do some Internet research to try to determine what Dan Mayer and Ben Brinckerhoff are doing today.