3 ms·

We are selling SaaS/B2B and are looking to support both modes moving forward. Our (my) preference is heavily tilted towards cloud, but we've modeled things to m

We are selling SaaS/B2B and are looking to support both modes moving forward. Our (my) preference is heavily tilted towards cloud, but we've modeled things to minimize our pain for on-prem. Path A: Run a windows server VM and SQL Server somewhere in our customer's infrastructure. Our customer is 100% responsible for the health of these items and provides them as a service to us. Our customer has to notify us of any infra or app issues reactively. Path B: We operate as custodians in our customer's Azure tenant. We deploy our software as a Function app and use Azure SQL. We are 100% responsible for the health of everything. Our customer is notified proactively of any issues. To support both paths, we have two different executable project types (console app and azure function app) that consume a common library type. Only the barest boilerplate code actually changes between on-prem and cloud. 99% of the difference is HTTP Trigger function vs AspNetCore hosting syntax. Everything else is identical. We work with small US banks and we haven't found one that is total stonewall against moving to cloud. Many are cautious but open. The #1 concern is the PII/data. We've been working with a few angles to cast that in a more realistic light. Most of our customers have had some degree of an incident with on-prem infrastructure that could have been made impossible if business was being conducted via a cloud provider.

dehugger 3y ago
Path C: Sell installable software with documentation (and training courses if you are big enough). You'll still get yearly revenue via license fees. I don't know why this went out of fashion but it works just fine. Your customers clearly don't want you to manage the infrastructure, based on your comment. Sell them what they want. If the issue is that your system is so complex that a reasonably trained admin cannot manage it, you should probably fix that.
- bob1029 3y ago
  If you want to go all the way into the rabbit hole: the entire purpose of our system is to provide interfaces into various lines of our customer's businesses. What our customers want is a technology partner who can adapt to their changing business needs over time. A one time cdrom+pdf distribution unfortunately will not get the job done in this case. Our customers are paying for a business outcome. Our software is just a fraction of that puzzle.
  - dehugger 3y ago
    That's a very obtuse take. Plenty of modern software follows this model; updates for locally installed software is hardly rocket science. I work with a vendor that provides shipping rate software which requires updates at least weekly. Still locally installed and licensed.

dehugger 3y ago

Path C: Sell installable software with documentation (and training courses if you are big enough). You'll still get yearly revenue via license fees. I don't know why this went out of fashion but it works just fine. Your customers clearly don't want you to manage the infrastructure, based on your comment. Sell them what they want. If the issue is that your system is so complex that a reasonably trained admin cannot manage it, you should probably fix that.

bob1029 3y ago
If you want to go all the way into the rabbit hole: the entire purpose of our system is to provide interfaces into various lines of our customer's businesses. What our customers want is a technology partner who can adapt to their changing business needs over time. A one time cdrom+pdf distribution unfortunately will not get the job done in this case. Our customers are paying for a business outcome. Our software is just a fraction of that puzzle.
- dehugger 3y ago
  That's a very obtuse take. Plenty of modern software follows this model; updates for locally installed software is hardly rocket science. I work with a vendor that provides shipping rate software which requires updates at least weekly. Still locally installed and licensed.