Dec 7, 2007 by Sinclair Schuller
A SaaSBlogs reader recently sent me a link to an article by Dharmesh Shah over at OnStartups. In a nutshell, the post articulated that building a highly scalable architecture when creating a new application is premature and creates a large resource tax on a startup’s already limited resources. This led to a vibrant thread of comments with people arguing both sides, but one comment by Dharmesh really stood out (and surprisingly wasn’t even acknowledged in the remaining comments) was the following:
“One point I didn’t make in the article, but probably should have: When making tradeoffs regarding scalability, you are at some level incurring technology debt. Debt is not always a bad thing — it can often help you grow. The key is to make sure that the “interest rate” on the debt does not outweigh the benefit of the tradeoff. So, if making a scalability tradeoff will likely cause you to rewrite the entire system, it’s probably not worth it. But, if it’s simply a matter of “Pay X now or 1.2X later”, it might be better in some cases to just pay 1.2 X later”.”
This comment provides sound rationale to the “should I scale-proof my offering early” question. From the standpoint of an entrepreneur, don’t waste your resources if scaling is not your core business (because some products have that as a core function) or if the cost massively outweighs the benefit since your immediate goals should include getting your first (or fifth, or tenth) customer, not worrying about your one-thousandth. That said, if you can scale proof your application at a low cost and avoid incurring technology debt, it’s generally wise to do so. Looking at the boundary cases, it becomes obvious. I offer you two choices: you can engineer your application for a cost of x and not be able to handle reasonably large scale or spend 1.02x and be able to deal with really large scale if and when it comes. Generally, you’ll choose 1.02x since the cost is negligible and the risk mitigation is high (this is why we pay for health, auto or any other insurance). Conversely, if I told you that the cost was x but that engineering for scale would be 1.2x or worse (say even 2x) you would most likely opt out and rightly so. After all, imagine that auto insurance personally cost you the amount of a car each year, you’d likely do everything possible to avoid getting it (granted, there are intricacies such as personal injury, etc. but work with me here! These non-tangible intricacies even exist in software – it’s one thing if you’re app doesn’t scale and you can’t take on new customers, but what if it grinds operations to a halt long enough that you lose existing customers or reduces the stability of the application to zero)
The goal of SaaSGrid, aside from providing an execution runtime and business services for SaaS offerings, is to allow for scale-proofing a SaaS offering at a negligible cost, biasing the cost/benefit analysis highlighted by Dharmesh toward choosing to scale rather than opting to incur debt. We strive to push for that trivial case of making the choice “obvious.”
If you’ve participated in building a SaaS offering, did you deal with the scale question early or late and how did your experience turn out? Have you ever had a “windfall”, a rare but possible scenario where you don’t experience organic growth but rather experience a large fluctuation in customer traffic due to some event?
read more
