Yes, Crash the Server

We’re trying out a completely new product, and the developer was anxious about posting a test release on a small server with limited capacity.

I can see why this makes him nervous. We’re used to the standards of assembla.com which is up about 2196 of 2198 hours in a quarter and has a core mission to be highly available. It has three layers of redundancy (in-box, local failover, and remote disaster recovery). It can crash, but it will bounce back, and it is unlikely to lose data. Many people rely on it.

The new service is different. This is what I said to the developer, who is in Brazil:
“We are not worried about scaling. We will only worry about scaling if we get a lot of users and crash the system. If that happens, I will send you a bottle of very expensive rum. That is your goal: Crash the server with traffic.”

The point is, in a first release, you want traffic or “engagement”, not reliability. In a product with many users, you want reliability. Set priorities differently for different stages of your product.