Depends on how much work it is. I would try to price it as my SaaS fee plus a consulting fee where the latter is NOT flat rate. Because this kind of arrangement turns you into a consultant.
I'm in a similar boat as you, having tens of on prem servers hosting our app.
Provide options to your customers as to what they should pay and what level of support they will receive.
Server goes down mid-day, or mid-night, who's going to fix it?
New release is ready for deployment, how is that going to happen? During their business hours, or outside of your business hours?
Are they going to need customisations that are out of scope of your product? If you ask now, they'll say "no", but it really means "no, I don't understand the depth of your question". How are you going to handle that? (hint: feature flags and if statements, avoid having separate codebases).
We try to automate as much as possible, to the point where we can deploy to a bunch of on prem servers, or a single hosted one, with the same tooling and process. It's not perfect, it's not `heroku deploy`, but it's good enough for us going forward.
We use a combo of ansible, docker, and WireGuard to pull this off, but there are paid alternatives if your clients can afford it (like tailscale, replicated, teleport, etc).
Hard to give advice without knowing more about the nature of the product.
But in general you should try to avoid it. If you want to go ahead with it charge a huge huge premium for it.
It can be good money to get a young SaaS going but as soon as you go from "your 1 instance of your app" to "N instances of your apps run by random customers" it changes everything.
Are they data sensitive in terms of trusting your saas to survive and wanting export/backups? Or data sensitive in terms of not trusting the security of your saas to secure certain pieces of sensitive data?
If it's the second, one idea I have considered building is a proxy operated by customer that replaces sensitive data with a token and then passes it onto your systems. Any responses that need to display/reveal the data can then have the sensitive data swapped back in based on the permissions of the user making the request. This puts the sensitive data fully in control of the proxy and it never touches the saas app.
Thank you! Data-sensitive in terms of the enterprise company not trusting the security of any SaaS app, even if they are Soc-2 compliant. They want the peace of mind that the data is on their side, but still doesn’t want to self-host it.
Another option might be a multi-tenant compute/data architecture where everyone is NOT run on the same compute/database, and instead is in a serverless single tenant architecture in different cloud accounts.
The multi-tenant part of your saas would amount to pushing regular automated updates to individual cloud accounts each with it's own serverless compute/data infra. This should make the core app simpler to build, and push complexity of multi-tenant into systems to manage the apps. Also you could get geo benefits by putting compute/data closer to where it's used. With serverless it should be more cost competitive than the days of operating actual servers.
Depending on your market focus and potential of less demanding customers, it also might make more sense to just avoid these large "semi-custom" customers which will no doubt be very time consuming and need many special features that no one else cares about. If you spend time building those customizations out, you are then stuck managing them after said large customer leaves. I have seen this happen and am wary of any single large customer feature "demands".
I'd start by digging deeper on their requirement to see if it is absolutely crictial. Then it would be import to know what is really required to comply with the requirement. Can you just have a DB at their location and you'd still host the app remotely?
Assuming the above doesn't help, there are a few sets of questions that should be answered.
Infrastructure and local support resources:
- Will you be deploying hardware to their site or do they already have existing infrastructure?
- Do they have internal resources to maintain either scenario above?
- Will your support be limited to just to your software if they don't have internal hardware support?
- Does the app need to function "offline" from the internet?
- Do they have external users who will need access to the app?
Commercial:
- Will your commercial arrangement be a typical Saas with a regular fee? Or they now expect to have perpetual ownership of a license?
'Replicated' has been doing SaaS setups locally (on-premise) for a few years and I've heard good things (though haven't used them myself): https://www.replicated.com/
Before you decide any technical solutions, do the business decision first. Are you willing to and/or capable of doing this ? For example, what percentage of revenue will come from these 2 customers overall and does it add up in the long term vision for your company ?
Lets say you decide to do it. Then make sure you are charging like 5-10x premium just to even entertain the idea. This is what you will call "Enterprise" and charge for EVERYTHING. Remember that if you deviate from your regular deployment etc, you will have to add extra work to support and maintain these additional things. So charge for those as well.
More importantly, if it doesn't align with your business vision, don't do it unless you are struggling to pay bills or interested in this space.
Source: I run a SAAS where we ended up doing mess like this and even though we charge more for that stuff, it has not added up for us in the overall direction/vision because we want to be a pure multi-tenant fast growing SAAS and don't have teams to handle too much enterprise yet.
I agree with your approach in taking a step back to observe the business case first BEFORE diving into technical discussions. It does get into the weeds and can stretch your resources thin.
Can you give them their own AWS account? If you’re using any kind of IaC, this should be manageable. Just make sure you charge enough to make it worthwhile taking on extra complexity.
Perhaps it’s a data jurisdiction issue? Are you deploying in their region? If it’s only data sensitivity can you provide regular ability to backup and also export data, as that may alleviate issues there.
Yes. There are a few companies that cannot have data leave their region. I'm hearing this is a huge pain in the ass. I like your idea of having the ability to backup and export data.... hmmmmm
Locally, onsite on the company's own servers? Or locally, as in "deploy it to servers in one of the European AWS regions".
If it's the latter, it likely easier. If you already have CI/CD, you are probably automatically deploying to different lower environments, and to production. Like this, you would need to set up additional production deployments to other regions. It has a cost, but you might be able to build on top of a lot of what you've already built.
If you need to deploy the software to on-site servers at some company, and it's not on the same cloud host as you are currently on, and you won't have access to the servers the same way you have access to your current production servers, then t's a much different ballgame.
Docker solves this problem. Could be coupled with other technologies (VPNs, etc.) but that's effectively what docker does: abstracts the app from the deployment environment.
You probably need to setup a delivery channel (a docker registry) and a release lifecycle scheme.
There are only two real issues here: How to pull it off technically, and How much to charge for it.
Price is the thing that's going to kill this deal, so we may as well tackle it first. It will cost your customer ~1,000X the monthly price to get this done. That's 5 figures, minimum, and it should be toward that high side of that range.
And we're done. 90% of the time, a ballpark estimate will realign the customer's idea of off-the-shelf vs. custom software, and you'll either never hear from them again or they'll decide that you know what? It turns out we can actually run off your servers after all.
But what about the guy who you couldn't scare away with your $34,000 delivery fee and bump to the $600/month Enterprise Plan (billed annually up front)? Well, now you have 6 weeks after the check clears to figure out how to deliver.
I've done this with both of my SaaS products, and the process is the same. Take the current version of the app and start lopping things off. All the marketing, pricing, billing, etc. goes. Database gets built from schema and lookup tables populated. Kill the customer registration (after using it to create customer #1 for them), but leave the Team stuff in place so that they can add their own logins. Replace the landing page with a redirect to the login screen. Smoke test it a bit then burn it onto the customer's VM of choice.
If they want to purchase updates with new features, make it expensive enough that you can do this whole process again every 6 months. Personally, I've always sold "maintenance only" contracts that guarantee timely fixes for stuff you broke in the last paragraph, with functionality frozen as of the date of purchase.
But yeah, it's actually quite fun doing the implementation of one of these. And a lot less work than you'd expect. Again, though, it's unlikely you'll ever get the chance to do it for the two customers who are interested today because if you price it correctly, you'll scare them away.
Here's looking forward to the one who ends up pulling the trigger!
Talos Linux + Kubernetes, Rook (Ceph) storage, Cilium for networking, K8s cron and Tekton for cicd pipelines and misc tasks. There are Helm charts for all the software that would run on this.
Can run on three servers, more servers can always be added.
You could offer it an a managed service and the customer would have to do basically nothing but provide inputs on what version of the software they want running, maintenance windows, etc
If the customer were to own the Kubernetes parts they are all commodity components.
Talos Linux is a unique Linux distro in that it's sole purpose is to run a K8s cluster. The Talos team is accessible and they have reasonable commercial support options.
31 comments
[ 3.6 ms ] story [ 68.3 ms ] threadMake sure you charge these customers for the extra value they are getting, though.
Hard to comment more without knowing more details, though.
Provide options to your customers as to what they should pay and what level of support they will receive.
Server goes down mid-day, or mid-night, who's going to fix it?
New release is ready for deployment, how is that going to happen? During their business hours, or outside of your business hours?
Are they going to need customisations that are out of scope of your product? If you ask now, they'll say "no", but it really means "no, I don't understand the depth of your question". How are you going to handle that? (hint: feature flags and if statements, avoid having separate codebases).
We try to automate as much as possible, to the point where we can deploy to a bunch of on prem servers, or a single hosted one, with the same tooling and process. It's not perfect, it's not `heroku deploy`, but it's good enough for us going forward.
We use a combo of ansible, docker, and WireGuard to pull this off, but there are paid alternatives if your clients can afford it (like tailscale, replicated, teleport, etc).
But in general you should try to avoid it. If you want to go ahead with it charge a huge huge premium for it.
It can be good money to get a young SaaS going but as soon as you go from "your 1 instance of your app" to "N instances of your apps run by random customers" it changes everything.
If it's the second, one idea I have considered building is a proxy operated by customer that replaces sensitive data with a token and then passes it onto your systems. Any responses that need to display/reveal the data can then have the sensitive data swapped back in based on the permissions of the user making the request. This puts the sensitive data fully in control of the proxy and it never touches the saas app.
The multi-tenant part of your saas would amount to pushing regular automated updates to individual cloud accounts each with it's own serverless compute/data infra. This should make the core app simpler to build, and push complexity of multi-tenant into systems to manage the apps. Also you could get geo benefits by putting compute/data closer to where it's used. With serverless it should be more cost competitive than the days of operating actual servers.
Depending on your market focus and potential of less demanding customers, it also might make more sense to just avoid these large "semi-custom" customers which will no doubt be very time consuming and need many special features that no one else cares about. If you spend time building those customizations out, you are then stuck managing them after said large customer leaves. I have seen this happen and am wary of any single large customer feature "demands".
Assuming the above doesn't help, there are a few sets of questions that should be answered.
Infrastructure and local support resources: - Will you be deploying hardware to their site or do they already have existing infrastructure?
- Do they have internal resources to maintain either scenario above?
- Will your support be limited to just to your software if they don't have internal hardware support?
- Does the app need to function "offline" from the internet?
- Do they have external users who will need access to the app?
Commercial: - Will your commercial arrangement be a typical Saas with a regular fee? Or they now expect to have perpetual ownership of a license?
- How will you protect your IP?
- Will they accept a lower SLA?
Lets say you decide to do it. Then make sure you are charging like 5-10x premium just to even entertain the idea. This is what you will call "Enterprise" and charge for EVERYTHING. Remember that if you deviate from your regular deployment etc, you will have to add extra work to support and maintain these additional things. So charge for those as well.
More importantly, if it doesn't align with your business vision, don't do it unless you are struggling to pay bills or interested in this space.
Source: I run a SAAS where we ended up doing mess like this and even though we charge more for that stuff, it has not added up for us in the overall direction/vision because we want to be a pure multi-tenant fast growing SAAS and don't have teams to handle too much enterprise yet.
By the way, 1. export as in csv. On demand or schedule. 2. Backup in your saas in whatever makes sense with ability to restore.
Backup is only useful with restore
Edit: spelling
If it's the latter, it likely easier. If you already have CI/CD, you are probably automatically deploying to different lower environments, and to production. Like this, you would need to set up additional production deployments to other regions. It has a cost, but you might be able to build on top of a lot of what you've already built.
If you need to deploy the software to on-site servers at some company, and it's not on the same cloud host as you are currently on, and you won't have access to the servers the same way you have access to your current production servers, then t's a much different ballgame.
You probably need to setup a delivery channel (a docker registry) and a release lifecycle scheme.
Price is the thing that's going to kill this deal, so we may as well tackle it first. It will cost your customer ~1,000X the monthly price to get this done. That's 5 figures, minimum, and it should be toward that high side of that range.
And we're done. 90% of the time, a ballpark estimate will realign the customer's idea of off-the-shelf vs. custom software, and you'll either never hear from them again or they'll decide that you know what? It turns out we can actually run off your servers after all.
But what about the guy who you couldn't scare away with your $34,000 delivery fee and bump to the $600/month Enterprise Plan (billed annually up front)? Well, now you have 6 weeks after the check clears to figure out how to deliver.
I've done this with both of my SaaS products, and the process is the same. Take the current version of the app and start lopping things off. All the marketing, pricing, billing, etc. goes. Database gets built from schema and lookup tables populated. Kill the customer registration (after using it to create customer #1 for them), but leave the Team stuff in place so that they can add their own logins. Replace the landing page with a redirect to the login screen. Smoke test it a bit then burn it onto the customer's VM of choice.
If they want to purchase updates with new features, make it expensive enough that you can do this whole process again every 6 months. Personally, I've always sold "maintenance only" contracts that guarantee timely fixes for stuff you broke in the last paragraph, with functionality frozen as of the date of purchase.
But yeah, it's actually quite fun doing the implementation of one of these. And a lot less work than you'd expect. Again, though, it's unlikely you'll ever get the chance to do it for the two customers who are interested today because if you price it correctly, you'll scare them away.
Here's looking forward to the one who ends up pulling the trigger!
Can run on three servers, more servers can always be added.
https://talos.dev https://rook.io https://cilium.io https://tekton.dev
If the customer were to own the Kubernetes parts they are all commodity components.
Talos Linux is a unique Linux distro in that it's sole purpose is to run a K8s cluster. The Talos team is accessible and they have reasonable commercial support options.