I've recently been thinking a lot and discussing with my colleagues at HubSpot the implications of Saas (Software as a Service). We're looking at this from many angles: operational cost, development cost, support cost, etc.
One of the big advantages for SaaS startups is the opportunity to be economically efficient along many dimensions through multi-tenancy.
But, just because the opportunity is there doesn't necessarily mean that every startup is exploiting it equally.
In my online readings and research, I came across an article about the SaaS Simple Maturity Model. Though I'm not particularly fond of the name, the framework is very useful.
Here's my (even simpler) interpretation of the levels of maturity of a SaaS architecture:
Level 0 (Chaos); Every time you add a new customer, you add a new instance of the software. If the customer needs something specific, you change that software instance. Each customer is essentially running on their own "version" of the software. Yuck!
Level 1 (Managed Chaos): Every customer runs on the same version of the software and any customizations are done via configuration. But, you still have different instances for each customer (their own website, their own virtual server, their own physical server, etc.).
Level 2 (Multi-Tenant, Highrise): You've got all customers running on a single version of the software, and they're all running essentially on one "instance". The good news is that you're getting the benefits of multi-tenant (sharing resources across customers). Even better is that you're not writing custom code for each customer -- everyone essentially runs on the same version. The big challenge is that as you add more floors to your building (to stretch the analogy a bit), it gets more and more expensive. And, there are limits to how high you can build to accomodate a large number of tenants.
Level 3 (Multi-Tenant, Build-Out): This is when you've got multi-tenant, single version of the software model. But, you can scale-out (add buildings at will). This is optimal because instead of letting the architecture decide how many tenants you put into a building, you can let the economics decide. And yes, there is an optimal number of tenants per instance and this number varies on your situation.
Level 4 (Utopia): This is like Level 3, except you've figured out an efficient way to run different versions of the software on different "instances". You're doing this not because you're writing custom code for a customer, but because you want to run different code for different customers -- to try things out. The best example is having an "early adopter" instance where customers that want to use your latest and greatest features can do so. Helps them. Helps you. Helps everyone. As long as you're efficient about release management. [Note: This last one is my own fabrication and wasn't part of the original framework referenced above).
HubSpot, my startup, is currently at a Level 2 and shooting for Level 4 this year (with a brief stop at Level 3 as an intermediate point). The good news is that we're adding cusomers quickly so this is more than an academic exercise for us. We can actually rationalize the investment in terms of economics because the benefits that we get from improvement actually makes us money.
---
Are you a superstar startup developer in Boston? Consider applying to HubSpot. Help us figure out how to delight thousands of customers and make money at it. Share in the fun and success. You can email me at dshah [@] onstartups.com. If you have what it takes, we've got some awfully smart and passionate people you'd enjoy working with.