SaaS Deployment Options
You have a multi-tenant app. Two of your customers who are data-sensitive need your app deployed locally. What’s the best way to solve this?
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.
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!
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?
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.
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.
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".
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
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.
Make 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).