So you’ve written some software.  You’ve either developed it with SaaS in mind, developed it to sell it as traditional on-premise (but who wants on-premise these days??), or developed it for yourself and realised it could have a market value.  So now all you have to do is launch a cloud server and it’s a SaaS solution right? Wrong.

There are still a few major challenges that stand between you and SaaS success.  Get it right and you’ll sleep well at night, worrying only about how to add new features and gain more customers.  Get it wrong and you’ll be sleepless, worrying about stability, financial models, and service performance.

What’s your tenancy model?

You’re planning to have multiple customers.  Perhaps 100,000’s.  Are they going to share the same ‘instance’ of code, or have an ‘instance’ of their own?  Don’t think about how you manage the software now.  You should be planning ahead for when you have 100x or 100,000x more customers than right now. It’s a basic question, and your software architecture will make a big difference here, but the answer will have a major influence on how you manage your customers in the future, and have a significant influence on complexity and hence cost.

Here’s a hint; multi-tenancy is almost always the correct answer.  Why?  Single Tenancy = Complexity.  Complexity = Cost.  Separation of code, instances, OS, database etc. all comes with a small overhead of hardware, and a large overhead of complexity.  In the future, will you really want to manage 100,000 tiny instances, or a small number of large systems.

Now add to that argument capacity management.  Do you want to capacity manage by scaling horizontally at peak times, or constantly have a minimum capacity forced on you through the logical separation of code instances?

Ok, so there are downsides.  With a multi-tenancy solution you can’t be as flexible with your customers.  You might need to upgrade them all at the same time.  You might not be able to offer beta features to select customers.  But let’s not pretend this hasn’t been accepted (and solved) across the SaaS industry.  Take a look at MS o365 First Release for one way to solve this.  Or maybe a tick-tock approach giving a time window for a customer to upgrade at their choice.


This can be a shock to many people/organisations.  You’re a software provider.  You write code.  You do stand-ups and play table football.  That’s your culture.

When you become a SaaS provider you become a service organisation.  Your service is probably 24/7.  Running the software is now your problem.  Quality isn’t just about how fast you fix bugs, it’s about all aspects of the service performance: response time, data security, information sharing, provisioning, customer care…  Do you have customer portal for service updates?  Who will run your service desk?  What tools do you need?

Generally developers make terrible operators.  Don’t be offended.  Operators make terrible developers too.

Many of our customers use us specifically for this reason.  They’ve made some awesome software and they want to concentrate on developing new features that only they can write.  Operations is commodity that adds little value to the business.  So don’t do it, give it to someone else to do it for you. (Have you seen our Managed Services page?)


SaaS security is a complex issue.  You have a single repository with the sensitive data of 100,000’s customers.  Now you’re a target.

Not only do you have to cover the general security of the infrastructure (firewalls etc.), but you have to secure your code, probably put in place an application firewall to block sql injection etc., and run an Intrusion Detection System.  I’ll assume you follow best practice in cloud infrastructure security.

There’s more to do.  Does your customer have their own security requirements?  Encrypted disks? https (with their own certificate maybe?) We all hate having another logon to remember/write down so SSO is almost an entry level requirement these days.

You’re not finished yet.  How will you stop authorised customers from accidentally (or deliberately) seeing the data belonging to other customers?  Do you need to meet an regulatory or industry requirements (PCI DSS, ISO27001 etc.)?

You’re still not finished.  Did you use off-shore resources to develop the application?  Are they secure in how they operate when they support your application?

SaaS security needs to be developed in from the code up, throughout your infrastructure, and embedded in your processes.  There are no shortcuts.

Capacity Management

You’ve sensibly chosen a multi-tenancy architecture and that means you can easily scale your solution horizontally during the day/week/month to meet demand.  All you need is a couple of auto-scaling alerts to add or remove capacity based on demand.  Well, hopefully, but it rarely works that easily.  If’ you’re about to start writing a SaaS solution you can solve this easily, but 90% of software out there just doesn’t deal with scaling well.  Mostly because of session management.  KEEP ALL YOUR COMPONENTS STATELESS, wherever possible.  Offload state to redis or memcached. The same issue applies for automatic resilience, but hopefully that’s a less frequent event.

Luckily you’re using cloud IaaS to host your SaaS, so capacity is effectively infinite, but don’t think good old fashioned capacity planning still won’t bite at some point.  You’ll still have databases that grow, disks that fill up, and upper limits on vertical scaling.  You’ll still need to monitor your instances.  Even if they’re disposable, you will want to understand their performance to identify code and infrastructure bottlenecks.

Good monitoring solutions are a must here.  Make sure you can collect data from all areas to get the full picture.  Pull your cloud metrics and application response times together with your DB index fragmentation stats to get a single view.


You’re more than likely providing an SLA to your customer.  Even if you don’t, they will have high expectations.  SaaS should be always-on.  That means you need to detect issues and recover quickly.  We discussed stateless components and horizontal scaling.  Resilience can be provided by using the same mechanisms.  Spread your load across availability zones to provide minimal DR.

The key here really is failure detection.  You need to recognise when an issue happens.  Rarely do instances drop off completely, but they fail gradually.  Load balancers check TCP or HTTP availability but this tells us very little.  Write custom code that will execute on the HTTP health check that will give a more comprehensive service availability response.  Run multiple listeners if required, with one dedicated to health checks and others actually providing the service.

Orchestration & Automation

You’ve already realised you’re going to have huge customer numbers.  Right now you can handle the requests manually, but soon you’ll be inundated with requests from demanding customers wondering why it takes so damn long to do a simple task.  Instant gratification is the norm.

Orchestration and Automation are essential here.  Let’s face it, AWS (of huge cloud success) is just a bunch of data centres with an awesome orchestration engine.  Humans aren’t fast or accurate (or cheap) at this stuff, so don’t use them for it.

The good news is you can start small and build over time.  At the beginning though, make sure to capture the requests methodically (web form, service portal etc.) and put a human in behind to do work.  This will set the expectation for your customer that they need to self-provision, and will help you filter, organise and recognise trends for requests while they are manual.  As you ramp up and the requests get more frequent you can automate the process, reducing cost, improving accuracy and speeding up the service to your customers.  Do it only as it becomes cost effective to do so.


Last, but certainly not least, don’t forget to bill your customers.  You might have a simple subscription model, or per user model.  That makes life easier.  More difficult is a consumption based model that means you need to capture usage.  If that’s the case don’t forget to build the usage hooks into your code.  Think about how your model scales to determine the best pricing mechanism.


This article barely scratches the surface of the challenges involved in becoming a SaaS provider.  Hopefully it gives you some insight and helps you avoid learning the hard way.


LayerV provide Consultancy, Cloud Solutions, and Managed Service to help you make a success of your SaaS.  We’ve helped clients build software into SaaS and have experience (and solutions) with all the issues above and more.

Contact or call us on +44 (0) 845 544 0045