Ask HN: Large customer wants us to deploy SaaS on their own K8s?

1. Make sure you are charging them 5-10x the usual cost you would charge. For on premise, anything under 50K USD per year Minimum is not useful in my opinion.

2. Setup custom contract and SLA. Dont go with usual SLA. Charge additional for support/maintenance/Stricter SLA.

3. Charge implementation fee upfront. Possibly send consultants onsite and bill them good for that.

4. Do min 3 year contract. Anything less won't be worth it if decide to pull the plug on you after year 1.

Year 1 Cost should be close to 80-100K min.

Even with all this, decide if it is worth doing for you as a company. Yes you could earn good revenue but it is 1 customer. If you don't have the infrastructure/resources to handle their demand, is or worth it for you ?

But no matter what, Do not cave in and offer on premises at similar rates. Has to be at least 5-10x.

Yup - basically they don't want SaaS they want on-prem. That is a drastically different pricing model and should have a different SLA. I would go so far as to include into the pricing the cost of keeping engineers and support people on staff who know this particular build specifically because it is different than what you normally run. You would need to maintain the exact stack they are running to test patches, upgrades, etc.

If there is a security vulnerability somewhere in their stack that is running your app, that should be called out as well as not your problem (legally, financially). Similarly if they have access to your running system and muck it up somehow, also not your problem.

The large Target breach a few years back was because the HVAC system controls were adjacent to payment systems and attackers got in and installed credit card number swiping. I get their concern with having a vendor's stuff sitting on their network but you should be protecting yourself from them not maintaining things.

More boiled down, they want consulting services not product sales.

The OP’s decision is between product company and consulting firm.

Great advice. I worked with a difficult customer like this, and we’re able to come to a satisfactory outcome.

Building control projects usually have a grant or external financing component, so the wallets are often flexible.

At my last job I worked for a large software company that offered a PaaS that ran on AWS/Azure public cloud or on-prem OpenShift/K8s.

The lowest price for the PaaS on AWS for $5k/year. The on-prem minimum was $1M/year and the customer had to setup their own infrastructure with a list of required software and minimum versions we provided. If the customer wanted us to meet the platform SLAs, they had to pay for a monitoring service and provide a remote connection (usually direct connection to our private VPN servers) to our ops team.

The $1M entry point for on-prem meant that only customers who really needed an on-prem solution for security reasons actually went for it. It also meant they had an experienced infrastructure team. Lots of customers would say "IT doesn't allow cloud" at first, then change their story when they saw the price difference.

Note that the $5K/AWS was the smallest package, and the $1M/on-prem was comparatively (compared to public cloud) an extra-large package. So it's not an apples-to-apples comparison, but I'm just trying to provide some information.

I realize none of the above answers you question, but it's just data to help you decide if this type of customer is worth it.

There are two sound business options.

The first is to decide the potential (not actual) customer is not in a market segment you serve. Educate the non-customer to the simple fact your product doesn’t meet their requirements. Wish them well. Continue periodic relationship management in case their requirements change or staff change. And move on with your business.

The other alternative is to move into the potential customer’s market segment. This makes sense if doing so is significantly profitable. That means having a conversation about the potential customer’s budget. You have to know whether or not the budget matches the scope.

The simple economics is to charge enough to provide dedicated full time staff. Say three engineers so there is redundancy. At Silicon Valley rates with overhead, call it a million dollars per year….or better $100k per month. That breaks down to -$35/location/month so call it $50/location/month plus expenses. Which works to $150k per month. At that rate you can probably make it work and it is probably worth doing.

Revenue-wise, this customer works. It's also a household name brand that will significantly bolster our bargaining position, and improve our series X prospects. Just wonder if this is a problem many vendors run into, and perhaps there is a purely technical solution to it (i.e. isolated newer-k8s-in-older-k8s).

How often do you see something like this? Any workaround besides not working with the customer?

I worked on both sides. This is super common for large shops with tight IT policy. My previous job provide critical services to our customers, our source code is escrowed to the third party in case we go bankrupted. My current job, we dismiss many vendors who can't run their software in our AWS VPC. The idea of a vendor can control (shut off) our core business is not an acceptable risk unless the vendor is huge like MS, Oracle, AWS.

I've worked on the other side, with a large enterprise that requires ISVs to deploy their solutions within containers (deployed to k8s/rancher etc) in a closed off VNet.

The reason for this was a previous ISV's solution that was sending our customers PII data off to another cloud, and we had no way of monitoring or protecting that data.

With regards to your issue, have you discussed your product or SLA requirements if it were to run on-prem?

With 3000+ stores and no automation, it sounds like you need to have a conversation about appropriate CI/CD patterns. Ideally you should be publishing to a private container registry, and they should be responsible for deploying that container.

In our situation, we understood the limitations we were placing our ISVs in, with our infrastructure bounding their reliability. With regards to guarding their IP, we don't specify that we need access within their containers. We provide access to a private container registry, and appropriate compute and network access for their container to run.

I understand, however no PII is involved in this case. The primary motivation is that "they're always being hacked" (words of their security team), so they try to run a tight ship. I can understand that. I'm hoping to find some kind of technical solution to this, e.g. running a newer version of k8s with limited access on top of their EOL k8s 1.14. So far I didn't find anything.

Old k8s? Held to SLA but not allowed to run the service yourself? Run for your life!

Customers like this will make you a loss. Simple. Choose good customers.

Check out https://www.replicated.com/ and https://kots.io/

- cryptic UI that only works on a laptop they provide

Is the UI open source, maybe it has an API?

Unfortunately, not. It's one of those smaller companies that developed k8s management UIs that got bought by a bigger company that offers k8s-as-a-service. So there is no code, there is no open access, you need to "contact sales" to have a demo etc etc. In the end, it's very similar to e.g. Rancher, but without an ability to upload YAML files.