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.