On-premises vs SaaS vs internal tool, what to consider before making a decision!
March 10th, 2020
Whether you are starting a tech business or already have one, you will often have to rely on software that is not directly related to your product. You have your "business software" (the thing you are selling to your customers) and then you have things like billing, logging, managing errors, traffic analytics, etc. that need to be taken care of. They are not what you are selling but you need them for it to run. You need metrics to guide your next dev or measure if your last feature is a huge success or not. You need to be sure that there are no errors between your customer and his payment. You need to handle billing so that money flows into your business.
You have three solutions to solve these problems. You can either buy a SaaS, install on-premises software on your infrastructure or create an in-house tool to solve your problem. These three solutions have their pros and cons. Let's see when to use what.
You are a startup or a small structure
Go for SaaS. I mean, abstract your problems away and just pay for a solution. Most SaaS has a monthly fee that you can stop at any moment. No upfront costs, that's the best option for any starting company that should focus only on making their product better.
There is an exception if your business relies on very specific constraints like data hosting or things like that.
For example, you might run a company that handles health-related data. In this case, you might not want to have these data end up being logged in a SaaS software. You would break the law in some countries.
If you exclude these very specific cases, SaaS should be your default option.
You are a medium-sized company starting to get traction
At some point, your SaaS solution might become costly. For example you pay an error logging solution monthly for a number of errors and you now have to pay a huge amount of money to keep things running.
Then you should probably go for an on-premise solution that you can host on your own infrastructure.
Keep in mind that on-premises solutions have hidden costs. You have to pay one person or maybe many people to host them.
If things break, you are on your own! You might have to interrupt an engineer working on your product to fix a very important on-premises part of your business that broke unexpectedly. The context switch is very difficult for that engineer and chances are that he or she doesn't know much about the on-premise tool. The company developing the tool knows how it works. It's easier for them to keep things running flawlessly.
If you really want or have to run things on-premises, make sure that you have enough resources to allocate to maintaining these services.
What about creating a custom tool?
I would say that most of the time it's not a good idea.
Except if you intend to make it a SaaS or sell it, or have a very specific problem that other software can't solve.
If you have a very specific problem it's very likely that it is indeed part of your product. If it is a generic problem but you feel that the solutions on the market don't fill your need then maybe a few tweaks can be made so that it does. From my experience, if you deviate too much from what everyone else is doing, then it might be the right moment to take some time and take a look at what the others are doing.
There costs with doing things yourself as well as risks. Here are two examples:
First example: opt-in email
Your application need email confirmation for account validation. You decide to download a mail server on your computer and start using the API on your favorite programming language. First, you have to choose what server you want to use. There are at least 10 of them on Linux. Then you have to configure it and if you miss one step you could have your validation emails end up in the spam folder of your potential customers. And it would take some time before you figure out why nobody clicked the activation link.
There are also hidden costs! You are paying someone (or doing it yourself) to handle this service. It takes time and money. Time spent on setting up an email server is time not spent on your product. Seriously, pay $X upfront and use a solution that just lets you do some API call and everything works. An externalized solution is something you don't have to worry about, at least for the moment. When the solution is starting to get too expensive, maybe it's time to consider an in house solution but before that, just go for the SaaS.
Second example: a newsletter email
You have a blog and you want to create a newsletter so that you can keep your audience informed and sell them your premium content. Some non-free services handle that very well, but you'd rather go for a simpler solution that doesn't cost you a dime. So you create a gSheet form and decide to start gathering opt-ins like this and everything will go fine?
Except you can't just send emails to anyone in the USA. And failing to comply with the law can put you out of business very fast:
Complying with the CAN-SPAM Act is crucial, as the failure to do so may lead to regulatory scrutiny, steep fines of up to $16,000 per violation, and significant public relations and reputational consequences.
Would you take the risk of doing something on your own on a domain that you know very few about? I'm not a US lawyer! I'd rather pay for a SaaS solution that complies with the law than risk such fines.
Conclusion
Using a SaaS should be your default option. You must use your energy for the next move that will bring money in and reinventing the wheel is not a smart usage of this energy. You might be tempted to do everything yourself, especially if you are a technical person (I know, I'm one). But we tend to overlook other aspects besides the technical part. Things seem easy to do superficially but end up being very complicated due to external factors.
On the other hand, you shouldn't fall into the other extreme of having your core product in too many SaaS. You could have too much accidental complexity due to too many SaaS talking to each other. Time to market is important but being in control of what makes your business unique is equally crucial. Use SaaS with parsimony, just to offload your team from things that are not directly related to your product.