“The Building of Basecamp” Review

By Deane Barker on June 29, 2004

The 37 Signals PanelJason gesturing to...something.A screen capture on the projector.  The mass of hair is ...Ryan, I think.

I’ve been putting off posting about The Building of Basecamp because I was trying to get my hands on a picture. Neither Joe nor I thought to bring a camera, and the workshop was the first thing we did in Chicago, before Joe bought a disposable to shoot this great panaroma from the top of the Sears Tower.

Anyway, I can’t find a decent picture (Update: Jason let me use a few of his), so here goes —

The biggest thing I pulled out of the workshop is that you don’t have to follow all “the rules” to make something great. When you think about companies delivering services over the Web, you think about…org charts, support staff, call centers, requirements documents, functional specifications, etc.

37 Signals will blow this perception apart pretty quickly. There are just three guys: Jason, Matt, and Ryan. That’s it. They don’t even have a full-time programmer. David works for them part-time. From Denmark.

They don’t have bug tracking, or trouble ticketing. They have two folders in AppleMail: “fixed,” “not fixed.” Jason spends a couple hours a day answering support emails.

Most of all, these guys are laid back. Not to the point of irresponsibility, but to the point where it’s obvious they can maintain a creative groove amidst the ridiculous grind of supporting software. They talk about Basecamp as if they know they’ve already done something wonderful (and they have — if you don’t believe me, believe these people), and everything from here on out is just gravy.

They built Basecamp the way they wanted to. All of you guys stuck in the corporate software trenches, can you imagine that — building software the way you think it should be built, without stupid restrictions? Can you imagine turning out something that was less a product of the corporate machine, and more a…craft, that you put together with pride like the prototypical old artisan in some rural town?

As you can tell, it’s been a while for me.

The bottom line is that they built what they wanted to in the way they wanted to. They didn’t get hung up on logistial or technical hurdles — they just kept working towards a goal as if it was completely reasonable and normal for three guys in a shared office with no programmer to build something like this. Thank goodness no one told them they were being ridiculous.

Which brings us to the workshop. It was packed with good information. So much so, that I wish it had been a bit longer. A day-and-a half would have been good, but I think we were displacing some workers from the company they office-share with, so we ran from 10 a.m. to about 6 p.m. and glossed over some stuff towards the end.

They divided the day up into sessions: Marketing, Programming, User Interface Design, etc. They spoke for a while, then presented some FAQs on that subject, then opened it up for questions. The four of them (three guys from 37 Signals, plus the programmer who flew in from Denmark) handled it as a panel discussion.

They got high marks on the presentation (done in Keynote, no less). They were very Larry Lessig-ish, in that each slide was just a sentence or two and they spoke from there. No reading of bullet points, thank goodness.

Questions were plentiful. The audience was thick with geeks (only one woman, interestingly), and they didn’t hold back. Most of the questions were very intelligent, as were the answers, though sometimes the questioner was asking something expecting a very pat answer, when the truth was a little more nebulous.

Here’s a sampling of some of the topics they covered. I’m just scratching the surface here, as there’s too much to cover and I don’t want to steal their thunder for the next time they offer this:

  • Develop a set of “mantras” or rules for how you want things to work. Whenever you develop something, “test” it against the rules. For instance, “less software” or “project management is mainly about communication.” Make sure you stick to your own rules and your own principles.
  • Say “no” by default to any feature request. Make a feature work very hard to be implemented.
  • Remember that there are significant hidden costs with new features. Besides the actual time to code there’s (1) time spent supporting it, (2) unforseen changes that result because of it, (3) time spent documenting it, (4) the overall degradation of the user experience if it makes things more complicated, etc. Sometimes, the coding time is just the tip of the iceberg.
  • Start everything with the screen design. The screen IS the application. The screen drives the functionality, not the other way around. The screen design is the requirements document. (I know, I know — the hair on the back of your neck just stood on end…)
  • Get something built quickly. Iterate, iterate, iterate. Release early and often. Plan a major feature upgrade within 30 days of release.
  • When designing a screen, find the epicenter — the main section of the screen where the user’s eye will be drawn first. Design that and work outwards.
  • Be honest with pricing. Clearly display the price, and avoid any hidden fees.
  • Avoid preferences. Preferences can be cop-outs to tough problems. Whenever you have the user set a preference, you’re having them make a decision (Joel Spolsky’s book is big on this too). It’s more challenging to come up with a solution, and mandate it. As a result, Basecamp requires something like four fields to be completed and it’s ready to go.

You get the idea — there was enough of this that Joe filled up a dozen pages in a legal pad.

One of the more valulable bits was at the end when the showed us their mistakes. They had a half-dozen dead ends and time wasters that they fessed up to, including what they called a “billing fiasco” into which they sunk a dozen hours of work without checking with their credit card processor as to the validity of what they were planning to do. It turned out the processor wouldn’t let them do it, and they lost a dozen hours of the programming as a result.

Any complaints? A few:

  • The chairs sucked. I’m 6’4”, 280 lbs. and that chair was so small it damn-near gave me a wedgie. And no tables — just rows of geeks trying to balance laptops on their…well, laps. Early on, I found a table in the back with a more comfortable seat.
  • It was hot in the room. Forty people in one room will do that, and I kept wanting to crack a window.
  • While they presented frequently asked questions that they had hyped in the promotional materials, they didn’t always answer them soundly. But, in retrospect, I don’t know what I expected. For instance, when it came to which platform to program in, I guess I was expecting a sound answer — do it in this platform. Looking back, this was just an unrealisitic expectation. What they did was tell us what they did and why, which is really all you can ask for.
  • Again, the workshop was a bit too short. If it had been another half day, the attendees would have come back on the second day with so many questions that occured to them overnight. I thought up a dozen on the plane ride home.
  • It was hard to hear from the back. They did it sans sound equipment, which is fine, but the Metro train went by the window just to my right about once every 10 minutes. I should have said something.

But I’m nit-picking now. None of this detracted from what was otherwise a great presentation.

Finally, this discussion wouldn’t be complete without talking about the office: very cool for a hick from South Dakota. All painted brick, open spaces, and hardwood floors. The prototypical “loft” office space. The trendiness of it all was a little over-whelming.

(Joe made a very astute comment when one of them started talking about business mistakes of the past. He said, “I find it ironic that he’s talking about the evils of the dot-com era while he’s standing in front of a foosball table…”)

37 Signals and their office mates are big, big Mac users. I didn’t see a single PC, and theatre displays were the norm. They had gorgeous equipment lying around everywhere. It goes without saying that they had an open wi-fi node running.

There was one bathroom, which meant there was a line, but it was worth it when you got inside. The walls were lined with chalkboards. The topic of the discussion was “Rejected Names for Basecamp.” Additionally, several people had written backwards on the board behind the mirror so you could read it normally in the reflection. Clever, no?

Lunch, incidentally, was fantastic. I had a turkey and avocado sandwich on a hard roll that about made me cry. (And you wonder why I was too big for the chairs…)

All in all, an excellent seminar on two levels: (1) the actual information presented, and (2) the vibe you got from 37 Signals in general. I came away with a very, “if they can do it, so can we” attitude which will perhaps be the biggest benefit of all in the next few months.

Something is coming from Sling & Rock. Stay tuned.

Next Steps —
What Links Here


  1. Wow, thanks so much for that kind review. We’re glad you found the workshop valuable, and thanks for the feedback about the negatives. We’ll work on those.

    FYI, we’ll be announcing a second date shortly. Stay tuned to http://www.basecampHQ.com for the announcement.

  2. Jason spilled the beans on the name:

    “Ever since the META and SETI project has been analyzing radio signals from space (and there have been billions/trillions), only 37 signals remain unexplained. At least that was how many in 1999 when we started the company.”

    Hang on — we’re going to have a geek core meltdown here in a minute….

  3. “They built Basecamp the way they wanted to. All of you guys stuck in the corporate software trenches, can you imagine that — building software the way you think it should be built, without stupid restrictions?”

    Of course, 37S has it good: they’ve got a successful enough business that they can afford the non-billable time to design and develop unproven things like Basecamp. Getting a regular paycheck in the corporate software trenches does have some appeal!

  4. Thanks for the GREAT review! I have been following 37S for some time (I’m in Uganda, East Africa!), and I think they are doing some wonderful stuff.

    This review just goes to show how wonderful it is. Keep up the good work guys!

  5. One pretty severe warning: when you’re using any of 37signals’ products such as Basecamp, make sure you backup your data thoroughly and often, in case the site has a bug or goes away. As a user of one of 37signals’ previous products, Singlefile, I had over 3000 book records in their database. At a certain point, their export function ceased working for me. I alerted Jason to the issue, but the problem wasn’t fixed. Then they took down the site two months later — so no data.

    From an outside perspective (they have refused to address the issue, nor followed through on their promise to get me a copy of my data, over 6 months after the issue first occured), it looked like the product simply didn’t scale to this number of records. Their customer service response has been pretty dire. This was the last message I received from Jason, back in early March:

    “At this time exporting a single person’s data for a service that is no longer available, was run for free over the past year, and isn’t even on a machine that can facilitate the export is simply not at the top of our list.”

    Which you might imagine was rather annoying, since the export of the data had already been requested well before the site was shut down, and was only necessary because of a bug they didn’t fix. It’s also not a stellar example of responsive customer service and the transparency they mention on their Basecamp Manifesto.

    There’s a reason that you don’t usually make your evangelist your tech support person… and having one part-time programmer is not exactly reassuring.

  6. Note: the issue with my Singlefile data has been resolved satisfactorily and amicably.

  7. Dear Singlefile User,

    That’s the kind of customer support I’ve received from 37signals as well. I totally agree with you about having the CEO running frontline tech support. Talk about cutting corners in a bad way.

    Jason is curt to the point of being rude and for some reason is surprised to find that he generates ire from his customers for his disobliging support.

    Sort of fits into the no tables or proper chairs in too small a room for the fifty people spending $500/each ($25,000) for eight hours of his time.

    Their XML export option for Basecamp is inconvenient (no useable file immediately) and limited (messages only). It would be no trouble for them to make a static HTML version of your project downloadable.

    So the promises about exportability ring a little hollow.

    In any case, I’m glad that the Singlefile data issue has been properly resolved for the Singlefile User.

    My issues were not and my experience with 37signals has made me very wary of hosted software (for which no version of source is available).

    Very good write-up. Thanks.

Comments are closed. If you have something you really want to say, tweet @gadgetopia.