The Builders of Basecamp

by Marc Hedlund

At the Emerging Technology Conference later this month, Jason Fried, president of 37signals, will be presenting Lessons Learned While Building Basecamp, a short form of the company's successful "Building of Basecamp" daylong tutorials. (The next full-day session will take place April 22 in Chicago.)

Basecamp's success as a bootstrapped web-based application has made it a favorite of web designers and also a model for would-be entrepreneurs. I spoke with Jason this week about 37signals, its history and products, and Ruby on Rails, the up-and-coming open source web application framework spun out of Basecamp's development.

Marc Hedlund: What is 37signals? Where did the name come from?

Jason Fried: 37signals started as a manifesto in 1999. We wanted to launch a web design firm that was focused on clean, fast, usable designs, and our manifesto was a series of statements covering our feelings about web design. In 1999 everyone else was elbowing for the loudest, brightest, most colorful, techiest "full service end-to-end" site. We went the opposite direction.

We've definitely had a good time along the way. We even poked some fun at the whole new media industry back in 2000 with eNormicom. Last year we released a book called Defensive Design for the Web. DDftW is all about making mistakes well and designing for when things go wrong online.

O'Reilly Emerging Technology Conference.

Up until recently we've remained a web design shop, but our focus on Basecamp, Ta-da List, and our new product in development (code-named "Honey") has transformed us into a product development company. We spend about 80 percent of our time on our products and 10 percent on client work. The remaining 10 percent is reserved for whatever we need to spend some extra time on.

Most of our client work these days is focused on our 37express offering. 37express provides one-page redesigns in a week for $2,500. 37express is perfect for companies that need one more design comp, rapid professional prototyping of a wireframe or early-design concept, or just a quick, hassle-free, "how could this page be better?" creative spark.

Where did the name 37signals come from? I'll defer to the manifesto.

Marc: Tell me a bit about the history of Basecamp. How did the idea come about, and how did it get from idea to reality?

Jason: We built Basecamp because we needed it. I'm a big believer in investing in what you know and what you need. We invested our time, energy, and focus into building a product that we knew we needed to run our own business. When you build what you know, and when you use what you build, you've got a head start on delivering a breakout product.

We'd been thinking of something like Basecamp for awhile. We tried some off-the-shelf and open source blog tools, but they just weren't right for what we had in mind. We looked at some of the other tools out there, but they all seemed to be built for bigger "small" companies. We're four people--and passionate about usability and simplicity--and we didn't find anything that really spoke to us. Nothing excited us. Everything was more, more, more instead of less, less, less.

Eventually, we resorted to building client extranets manually. Each time we had to report an update to the client, we had to go in and manually tweak HTML. Maintaining the extranet became more work than the client projects themselves. Well, after a while the same thing happened to everything that's a pain to use--it didn't get used.

So, we decided to build Basecamp for our own internal use. We didn't really put much thought into making it a product until a few months in when we started showing it around. We kept hearing "Man, I need this" or "How much?" or "Finally!" We also knew there were thousands of other companies just like us--small three- or four-person shops that never really thought much about project management but knew project management was something they really should be taking seriously. We wanted to build a project management application for companies without dedicated project managers. So we pressed on and built Basecamp into a simple, hosted, subscription-funded, web-based application.

We launched Basecamp on February 1, 2004, after about four months of design and development.

Marc: Basecamp is very different from Microsoft Project, another piece of software intended to help project management. Obviously, you've come at the problem of project management with a different philosophy--what is your approach, and what led you to it? Is Basecamp different from Project because one is a desktop app and one is a web app? Could Basecamp be written as a desktop app and be successful?

Jason: Our baseline approach is this: project management is communication. Projects don't fail from a lack of charts, graphs, tables, reports, stats, spreadsheets, and so on. Projects fail from a lack of simple two-way communication.

Traditional project management tools like Microsoft Project are about broadcasting sheets of data, not facilitating two-way communication between humans. They are used by project managers to make charts, track time, build reports, and then blast them out. Traditional project management applications transform the project manager into a taskmaster. "See this Gantt chart? This is how this project should be built--now go build it!"

The problem is that real-world projects don't run like an organized, Gantt-charted project plan. Real projects are chaotic: missed deadlines, miscommunication, scope creep, new initiatives, new people in, old people out. There's a lot of stuff to be said, but nowhere to say it, store it, and organize it. That's where Basecamp comes in.

Basecamp democratizes project management and makes it a team effort. Basecamp lets everyone get involved in managing a project--the thinkers, the builders, the managers, and the client. Anyone who has access to the project can subscribe to the RSS feed and be updated about anything that is posted to that project.

Basecamp embraces the openness, accessibility, and universality of the Web. You don't need fancy project management software (and worry about which version or platform you have). You don't have to ask your clients to install some new software on their computers (and deal with updates, patches, and so on). You don't need to worry about Mac or PC. All you need to use Basecamp is a web browser and an internet connection. Every firm and client has access to that and knows how to use that. That's standard issue. Plus, most people have that setup at home, so you're never far from your projects.

So, no, I don't believe Basecamp would be successful as a desktop-based app. It goes against everything Basecamp stands for. It puts up too many hurdles. Project management can't be a project in itself.

Marc: Over the past year we've seen some prominent examples of "high functioning" web applications that go beyond simple HTML interfaces; GMail, for example. Do you see web app functionality increasing because of browser features, or competition in the browser market--Firefox, Safari, and Opera--encroaching on Internet Explorer, or for other reasons? Are web app users different now--say, more comfortable with complex interfaces--than they were a year ago? Is your new Ta-da List product able to use new web features (compared with Basecamp at its launch) because of changes in the browser space?

Jason: I definitely think we're going to see the web-based customer experience changing (for the better, hopefully). Sure, we'll see more features, but features are easy. The hard part is not adding a feature. The hard part is deciding which features really make sense and then nailing them with the perfect interface, the perfect customer experience.

Modern web browsers help, but it still comes down to the basics-- making things easy, obvious, and useful for people. In fact, modern browsers have made things a lot more complex in a lot of cases because there's more and more and more "stuff" that's part of the browsing experience these days: plugins, frames, sidebars, toolbars, pop-up blockers, built-in RSS readers, and so on. It's all very confusing.

However, that being said, there's some great stuff happening today. XMLhttprequest makes the overall experience faster. Less reloads really make the Web a better place to work. There are some pitfalls, but we'll learn them as we all move forward and hopefully we'll see some best practices filter in.

But again, it's not the tools that make or break the experience, it's the application and execution of those tools. Flash is the poster child here. Flash doesn't suck, but a lot of the stuff done with Flash does.

Marc: As application developers, what do you want from browser makers? Do you want "less software" from browsers, as you advocate for Basecamp users?

Jason: I want consistency that works. It's absolutely ridiculous that in 2005, "standards compliant" code doesn't work the same in all major browsers. What's the point of standards if people don't follow them? Thankfully, Safari and Firefox are leading the charge toward implementing standards correctly (for the most part). I hope IE 7 will follow suit. The pressure is on.

So, while we advocate the "less software" approach with Basecamp, we advocate "more consistency and cooperation" from the browser makers.

Marc: Tell me about Ruby on Rails, and your choice of Ruby for a development language. Have you been happy with the use of Ruby? Do you think users are more comfortable with Basecamp because it is based on open source?

Jason: Ruby on Rails is the open source web application framework we extracted from Basecamp. When we built Basecamp we didn't know we were building Rails at the same time, but that's exactly how it happened. Basecamp came first; Rails was born from Basecamp. Basecamp was the divine chicken, Rails was the egg.

I had some natural hesitation about using Ruby at first ("What the #@!* is Ruby?" "Why don't we just use PHP--it served us well before?"), but David Heinemeier Hansson, the first engineer on the Basecamp project, cogently made the case and I bought it. I'm thrilled with the results.

The way I look at it is this: I want developers to be comfortable with their development environment. I'm a designer and a business guy, not a developer. I'm not going to push PHP or Java or whatever just because I've heard of it. I'm going to defer to David on this. And if David chooses Ruby, then Ruby it is. It's all a matter of trust. If you don't trust your developer to choose the right environment, then how can you trust him to build the best application? Trust is critical here. And, further, why would you dare impact your developer's morale by throwing him or her into a language where he can't be as productive or as satisfied? You only get good work from people who enjoy doing the work. I'll take a happy average programmer over a disgruntled, frustrated master programmer any day.

As far as Basecamp being based on open source under the hood (Ruby the language and Rails the framework), I don't think they know or care. They just want a product that works, and if Ruby makes it easy for us to enjoy building the best product we can, then our customers will indirectly enjoy Ruby and Rails.

Marc: What are some of the unexpected uses of Basecamp that you've seen? Did use of the application match what you thought it would be when you set out?

Jason: When we built Basecamp we wanted to be sure we didn't make it too genre specific. Less software keeps things general by default, so we already had that going for us. But other than that, we just wanted to build a tool that helped people get the simple things done. If they can't get the simple things done, then they can't get the hard things done. And most projects are filled with a bunch of simple things.

But here's the key: Basecamp isn't about doing it our way, it's about doing it your way. People are using Basecamp to manage their intense client engagements during the day, and their side projects or hobbies at night. Others are using Basecamp to manage their home improvement projects, their school projects, their classrooms, their customer support departments, their magazines and publications, their book writing process, their churches and synagogues, and even their weddings! Who would use Microsoft Project to manage their wedding? Exactly.

Marc: How have blogs helped to spread the word about Basecamp and Ta-da Lists? Do you think there is a particular match between the blog community and your applications?

Jason: Blogs have been absolutely key to getting the word out about Basecamp. We definitely bootstrapped Basecamp--we self-funded the development (and continue to self-fund it--we're debt and investor free). We paid every penny and have been investing in the product ever since.

We love the bootstrapping process, but it does come with its shortcomings. One of those is the ability to advertise. Advertising is expensive, and evaluating the effectiveness of the advertising can be even more expensive than the advertising itself. We didn't have the time or money to go the traditional route, so we went the guerilla route--the blog route.

Our Signal vs. Noise blog gets about 10,000 unique readers a week, so we started there. We got the word out on SvN and it just started to spread. Folks like Jason Kottke, the BoingBoingers, Jim Coudal, and a variety of other people with popular blogs really helped raise the visibility.

At its core, Basecamp is a blog--a blog customized and tailored more for project management. I think the resemblance to public-facing blogs really helped a lot of people "get" Basecamp at the start.

Ta-da Lists is a great example of the power of blog-based marketing. We launched Ta-da with a single post on Signal vs. Noise, and a few weeks later it was mentioned on over 200 blogs and over 12,000 people signed up for their own Ta-da account. I don't know any other way to get that sort of traffic without paying a dime for it.

Marc Hedlund is an entrepreneur working on a personal finance startup, Wesabe.

Return to the O'Reilly Network.