Software scalability seems to be a perpetual hot topic among web developers. The thing is, 99.99% of web applications have no need to worry about scaling – ever. The debate is just pointless rhetoric – although I do understand people’s obsession with it. It’s easy and fun to play the optimization game and run benchmarks. It makes for interesting discussions; it is not productive though.

If you’re building a start-up, ignore the debate and focus on what’s important: getting your product to market.

Pick a development stack based on iterability (yes, that’s not a real word), not on scalability; that is, a stack that will let you get out as many code changes and implementations as quickly as possible.

I’ve heard people say that “ruby on rails won’t scale”, or “django is inefficient” or “cakephp is for amateur developers.” Do these frameworks use extra CPU cycles for their ease of use? Yes. Will you ever notice this? No. If you do, congrats, you’ve made it – prepare for two months of no sleep, some expensive server (bandaid) costs and dashing to find people who have been here before to help.

The risk of not spending time on scalability up front:
- You lose some potential and current users from frustration once you’ve achieved success.

The reward:
- You get to market faster, which beats the competition
- You see if you’re idea is viable; and if not, move on or do another iteration.

Most startups are ephemeral; don’t spend time building a foundation for a skyscraper when you’ll probably end up with a shack.

Build many pretty shacks until yours becomes the “it” shack. Then build a house around that shack when it’s necessary. You’ll disturb some of the inhabitants of your shack, but at least you didn’t spend all your time building a house that no one is living in. Now you have a popular house that you can work on turning into a high-rise. Cheesy analogy, but it works.

So what do I mean by putting off scalability?
Example:
Team A: Picks the LAMP stack, uses a framework like code igniter, installs one cloud server and starts developing and releasing.

Team B: Picks the LAMP stack, writes their own basic functions in OOP that are “light”, shards their DB based on what they “think” will cause a heavy load, load balances their webservers, gets a mysql cluster running, builds memcached into their apps and now starts developing and releasing.

Team B probably had fun and also wasted valuable time and resources. Team A got their app up quickly, found out what users like and don’t like and can now handle scaling issues.

I’m not saying code irresponsibly – don’t put a SQL query in a loop that queries it 100 times when you could simply write a join.

Code with good practices, pick the best (read easiest) tools for the job and choose a very agile and popular development framework to get your product to market.