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.

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.

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?

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.