From the outside, it often seems like certain companies or products just blow up unannounced and become huge overnight. In reality, it rarely works like that. It certainly didn’t for us.

When we launched Basecamp five years ago, I think we had less than 2,000 people subscribed to our RSS feed. Add a few thousand more who were just checking the site manually and it’s probably reasonable to guess that our initial audience was below 5,000 people.

By today’s standards, that’s tiny! And that audience had even taken a few years to build. But it was what we had and it was plenty to launch a very successful suite of products.

It wasn’t enough to make us blow up overnight, though. To get today’s levels we’ve relied on the compound interest of attention. Every year a steady stream of new readers and customers have joined the flock while still keeping the bulk from the year before.

That’s why it annoys me dearly when our advice is discounted with “that only works for you because you’ve got this massive success to roll from”. That “massive” success was built convert by convert. Nobody handed it to us. We’re sharing exactly how we got there and hoping that our experiences and discoveries will help get you to where you want to be as well.

So stop thinking that you can’t get there because you don’t have a huge audience already. Start building that audience today. Start getting people interested in what you have to say. Then in a few years time you’ll get to chuckle about your overnight success as well.

“I’d love to start a company / become a great programmer / write an awesome blog, but there’s just not enough time in the day!” Bullshit. There’s always enough time, you’re just not spending it right.

Now that’s some tough love, but I’m sick and tired of hearing “no time” as an excuse for why you can’t be great. It really doesn’t take that much time to get started, but it does take wanting it really bad. Most people just doesn’t want it bad enough and protect their ego with the excuse of time.

This excuse is particularly depressing when it comes from students.

“Oh, I have so many classes. Oh, I have so much home work. There’s simply no time to learn outside of school.”

Then you’re doing it wrong!

Never let your schooling interfere with your education, someone clever once said. Being willing to sacrifice at the edges is one of the most important skills you’ll ever learn.

I’ve received plenty of Bs and even Cs for classes that I was incredibly proud of because they came from hardly no time spent at all. Time that I could then spend on reading my own curriculum, starting my own projects, and running my own businesses.

And I did. During my undergrad, I created Instiki, Rails, Basecamp, and got on the path to being a partner at 37signals. Do you think I could fit all that and still get straight As and have lots of time left over for playing World of Warcraft? No.

If you want it bad enough, you’ll make the time, regardless of your other obligations. Don’t let yourself off the hook with excuses. It’s too easy and, to be honest, nobody cares on the other side.

It’s entirely your responsibility to make your dreams come through.

We’ve been talking about the basic wonder of putting a price on your product for such a long time that it almost seems trite at this point. I certainly thought that point would have lost propulsion long ago, but I keep being surprised by the contrary.

It seems that the web has been so thoroughly infected by the memes of “the future is free”, “we’ll all live from ads”, “VC money will get us there”, and “acquisition is nirvana” that it has almost lost its faith in the simpler ways.

I’ve been approached by a great many entrepreneurs since the Startup School talk who all tell a similar story. They found a niche, made a product for it, and then thought “what the hell, let’s do something crazy!” and decided to charge money for it. To their surprise, it worked and they’re paying the bills and growing.

While that’s fantastic, it’s also perverse. There shouldn’t be any element of surprise unveiled from that order of actions. It should come as a natural conclusion, but it doesn’t. Because the startup culture has caught this disease that there’s something unnatural in being profitable from the get-go. That making money early means you won’t make it big later.

It’s depressing and it’s wrong, but I also think it’s going to change. I think the days of the traditional San Francisco startup approach are numbered. It’ll be flushed down the drain along with CDO’s and zero-down mortgages.

On the other side we’ll have a world where having a price will be the expected. A world where Jason can’t make headlines saying “free is not the future”. A simpler world where most people, even on the web, will live from direct customers.

I look forward to that day.

I love cats as much as the next person, but this fad to include LOLcats in every tech presentation was stale a year ago. Today it’s downright rotten. I wonder when the smell will be stark enough that even those putting slides together at the finishing line will think twice.

It’s easy to think that the relative-time style of “this comment was written 15 minutes ago” is incompatible with caching. How are you supposed to cache something if the text changes every minute? Static pages with JavaScripts, that’s how!

I put together a new mini app for our new status site yesterday that needed exactly this technique. I wanted the content of the application to be entirely page cached, so it would withstand the onslaught if the terrible should happen and we need to redirect all trafic to the status site.

I also wanted the relative time style, especially since it’s timezone independent and you don’t want people to think you’ve been down for two hours when it’s really only been twenty minutes because they did the timezone conversion wrong.

It looks like this:

To make this trick work, I embed the time stamp for a given entry in the DOM as a custom attribute that I can query for conversion like this:

<li>
  <span time="Feb 05, 2009 15:30:00 GMT">09:30 AM CST (15:30 GMT)</span> /
  The aliens came out of no where and took Basecamp!
  We're trying to hunt them down now. Stay tuned while we bring the lasers online.
</li>

I only want to convert the entries from today into relative time. The entries from yesterday and before should just use the specific time-only style. This means looking for just the span’s inside li’s from the ul with the class “today”. They’re then converted when the document is loaded with this function:

convert_all_times_from_today_to_words: function() {
  $$('.today li span').each(function(e) {
    e.innerHTML = this.time_ago_in_words_with_parsing(e.getAttribute('time'));
  }, this);
}

The function uses a simple DateHelper JavaScript class that mimicks the DateHelper in Rails.

This technique can be used for things other than just dates. You could imagine a cached page where you wanted the name “David Heinemeier Hansson” replaced with the text “You” if there was a match.

It’s a great way around otherwise cache-busting requirements.

WHO has recently shown that surgical deaths can be reduced by a third when hospitals follow their Surgical Safety Checklist. The checklist is very low tech. It includes questions like whether the patient has been properly identified, whether the proper tools are available, and whether everyone knows what kind of procedure is about to be done.

If a checklist so simple can save so many lives, I thought the technique could surely help us do better as well. So after reading about this study and their checklist, I’ve been pushing us to create checklists for all the common procedures at 37signals.

We now have checklists in Backpack for confirming that a feature is complete, we have a checklist for preparing the feature for deployment and for executing the deployment, and finally for verifying that the feature is working as expected in the wild. The last one looks like this:

It’s the kind of stuff that we all know, but that we’ll often forget if we’re not being reminded about it in the moment. Thinking back to the mistakes we’ve made in the past, there are plenty of those that could have been avoided or caught much earlier if we had been using checklists.

Think about what kind of checklists could help you save if not the lives of your customers, then at least their data and your uptime.

Service operators generally suck at saying they’re sorry. I should know, I’ve had to do it plenty of times and it’s always hard. There’s really never a great way to say it, but there sure are plenty of terrible ways.

One of the worst stock dummies that even I have resorted to in a moment of weakness is this terrible non-apology: “We apologize for any inconvenience this may have caused”. Oh please. Let’s break down why it’s bad:

“We apologize”
You say “I apologize” to someone when you bump into them on the subway, not if you spill your coffee all over them. Then you’re “really, really sorry!”. If your service is important to your users, it’s a lot more like spilling coffee all over them than it is like bumping into them when you go down.

Also, you should find someone willing to take personal responsibility. Even if it’s not directly their fault. There’s always someone who’s in charge, someone who stops the buck. Hiding behind a faceless “we” is weak.

“Any inconvenience”
First of all, if I depend on a service and can’t get to it, it’s not an inconvenience. It might bloody very well be a full-on crisis. An inconvenience is when I can’t get my flavor of milkshake at Potbelly’s or if there’s line at the grocery store. This ain’t that.

Using the word “any” makes it even worse. It’s implying that you don’t really care what bucket my frustrations fit in. Every feeling I have about this will apparently fit the “inconvenience” header. Wrong.

“This may have caused”
Again, this is slighting the very real experience that I am actually having right now. If this didn’t affect me, you don’t really need to say you’re sorry. If it did affect me, it didn’t “may have caused”. It caused! Stop wavering.

So what’s the perfect way to say that you’re sorry? Well, if I could come up with such a generic way, then it would probably sound pretty hollow pretty fast. There’s just no relying on a stock answer for these situations, but I’ve found the number #1 principle that helps me: How would I feel about it?

The most important part of saying you’re sorry is to project some real empathy. If you can’t put yourself in your users’ shoes, then it’s going to out wrong. So I try to pick a tone that’s proportional to how I would feel about the outage. Which is very situational depending on the length of time, the response, the updates, etc.

Oh, one more thing. Never, ever call an outage an “availability event”.

We’re going to be doing a 37signals Live show on Thursday now that I’m in town. Please join us with all your questions and we’ll do our best to answer.