Should You Trade Off Speed of Execution For Scalability?

Technology startups, especially when they are just taking off, are usually under great pressure to deliver the product or service and prove that it works. The goal is usually to build out the product as fast as you can, making whatever sacrifices necessary to get the product launched and out the door. The mantra becomes “Do whatever is needed to get the next round of money”. In pursuit of this, startups will usually make shaky technology choices to get the product out the door.

What ends up happening is that the product is built up on some hacked-up framework, and with each iteration building on increasingly shaky structures, putting on top even more shaky code until eventually the whole technology stack is a big wobbly mess and you’re praying the damn thing stands still while you’re demoing it to VCs. Sounds familiar?

The greatest example of this is Twitter. Around 2007, Twitter was quite popular among the tech crowd and it was just about to take off broadly, but it was notoriously unstable. Twitter kept going down, sometimes for many hours at a time. So much that Twitter’s “fail whale” become an icon in itself.

Twitter took well over a year to fix all the stability problems. It was extremely lucky to have survived - users stuck around the platform while Twitter was busy fixing the various scale problems. Many other startups were not so lucky. Users often don’t have the patience to hang around while a product is being fixed without the additional of any new features - They’d rather go over to the other guy that is building new and interesting things.

The usual argument against building for scale from the start is that it takes too much effort to “do it right”. The attitude usually is lets get it running now, and we’ll figure out how to scale when we get there. While this argument had some merit 5 years ago, I don’t believe it is the case today.

Take for example Groovy. It’s a scripting language that runs natively in a Java Virtual machine, and can interact with other Java objects and classes. You can use this to build the quick-and-dirty prototype, and when your product becomes popular, you re-write the critical pieces in Java with all it’s enterprise glory. And you won’t be breaking anything as you transition. It’s like changing the engine of an airplane while it is flying.

Making wise technology choices will really pay off. Can you use a messaging system to integrate your workflow instead of just arbitrarily building something in ruby or python? Apache has a excellent messaging broker - ActiveMQ that you can setup and run quite easily. And when the time comes to scale, ActiveMQ will distribute itself across machines, use persistence, support failover, remote monitoring, logging and auditing and much more. Try to see if your data can be stored in something like Cassandra, which can trivially scale from 1 machine to 1000s instead of using a SQL server (which can’t).

Making wise technology choices upfront can really save you time and money later on, and provide enormous amounts of flexibility as you scale your startup.