Depends on which model will be more beneficial to your customers and also be profitable to you at the same time. You can learn from companies like PostHog that stopped offering paid self hosted managed solution. Either you use their Open Core version yourself OR you pay for their cloud hosting. This article will hopefully help:
Answering from a customer point of view- sensitive, regulated or simply old fashioned industries will want to avoid using SaaS for sensitive material like credentials.
I think that the main challenge I faced, again as a customer, is support and maintenance- your software will run on an endless variety of platforms using different versions of it by people with varying competence levels and you'll need to support all of them
I wrote 5k words on the benefits and challenges of a self-hostable product[0] which may be useful to read. At FusionAuth, my employer, we have had both self-hostable and cloud versions for over 6 years. We started out with the self-hosted version and then added a cloud offering.
I'd start out with the business case. I'm not sure what "credential collection" is, but think about why your customers might want to self-host. Common reasons include:
- data sovereignty (legal responsibility towards users from a geography)
- data locality (data location)
- CONTROL (I put in all caps because that is an overriding reason)
- cost (esp if they have existing infrastructure your system can run on)
Devtools are a natural fit for self-hosting, as are other tools that target SREs, because the user/buyer is the operator and understands what they are getting into. Is the same true for "credential collection"? I dunno.
As far as pricing, we charge for features and support in one dimension, then hosting in another. (So if you self-host, the second dimension goes to zero.) That has been confusing to our audience[1]; one commenter said "your pricing sucks" :) . We're working to make that simpler, but it's a tough road because it is atypical.
Regarding development tasks, have your supported platforms and dependencies be as few as possible (we only require a MySQL or PostgreSQL database and an optional Elasticsearch/Opensearch installation).
Margins are way higher on self-hosted if you charge for features, but support will be much tougher. Build in some telemetry (in a transparent way your users can trust) to help your support team. Be prepared to hop on some video calls because sometimes telemetry won't give you enough info.
Also be prepared to draw some lines in the sand: is helping someone troubleshoot their proxy configuration in front of your software included? How about their database performance?
Product decisions will be harder too, but telemetry can also help there[2].
I'm deeply deeply against offering self-hosted SaaS.
In summary because it takes you from a world where 1 instance of your application exists under your full control to a world where 1000 instances of your application exists all over the place outside of your control.
At that point you turn into a "classic" software vendor where you have to help people "operate" your software. After you have long moved on from something someone will still be on the version from 3 years ago and talking to you about "upgrade/migration path".
I firmly prefer a world where there is only "one operator" for the product and I fully manage 1 instance of the product as a total black box and the end users use it as a ... hello? ... "as a service".
My advice is unless someone cares enough to write you a life-changing check ... stay away from it.
Depends on which model will be more beneficial to your customers and also be profitable to you at the same time. You can learn from companies like PostHog that stopped offering paid self hosted managed solution. Either you use their Open Core version yourself OR you pay for their cloud hosting. This article will hopefully help:
https://posthog.com/blog/sunsetting-helm-support-posthog
Answering from a customer point of view- sensitive, regulated or simply old fashioned industries will want to avoid using SaaS for sensitive material like credentials. I think that the main challenge I faced, again as a customer, is support and maintenance- your software will run on an endless variety of platforms using different versions of it by people with varying competence levels and you'll need to support all of them
Not really. Just ship a Docker image and anything else can fall outside of standard support.
I wrote 5k words on the benefits and challenges of a self-hostable product[0] which may be useful to read. At FusionAuth, my employer, we have had both self-hostable and cloud versions for over 6 years. We started out with the self-hosted version and then added a cloud offering.
I'd start out with the business case. I'm not sure what "credential collection" is, but think about why your customers might want to self-host. Common reasons include:
- data sovereignty (legal responsibility towards users from a geography)
- data locality (data location)
- CONTROL (I put in all caps because that is an overriding reason)
- cost (esp if they have existing infrastructure your system can run on)
Devtools are a natural fit for self-hosting, as are other tools that target SREs, because the user/buyer is the operator and understands what they are getting into. Is the same true for "credential collection"? I dunno.
As far as pricing, we charge for features and support in one dimension, then hosting in another. (So if you self-host, the second dimension goes to zero.) That has been confusing to our audience[1]; one commenter said "your pricing sucks" :) . We're working to make that simpler, but it's a tough road because it is atypical.
Regarding development tasks, have your supported platforms and dependencies be as few as possible (we only require a MySQL or PostgreSQL database and an optional Elasticsearch/Opensearch installation).
Margins are way higher on self-hosted if you charge for features, but support will be much tougher. Build in some telemetry (in a transparent way your users can trust) to help your support team. Be prepared to hop on some video calls because sometimes telemetry won't give you enough info.
Also be prepared to draw some lines in the sand: is helping someone troubleshoot their proxy configuration in front of your software included? How about their database performance?
Product decisions will be harder too, but telemetry can also help there[2].
0: https://fusionauth.io/blog/building-self-hostable-applicatio... . You can read more discussion about this post here: https://news.ycombinator.com/item?id=42527887
1: https://news.ycombinator.com/item?id=41269089
2: Here's an example of the telemetry we collect: https://fusionauth.io/docs/get-started/download-and-install/... . We try very hard to know nothing about our customers' users to respect our customers privacy.
I'm deeply deeply against offering self-hosted SaaS. In summary because it takes you from a world where 1 instance of your application exists under your full control to a world where 1000 instances of your application exists all over the place outside of your control.
At that point you turn into a "classic" software vendor where you have to help people "operate" your software. After you have long moved on from something someone will still be on the version from 3 years ago and talking to you about "upgrade/migration path".
I firmly prefer a world where there is only "one operator" for the product and I fully manage 1 instance of the product as a total black box and the end users use it as a ... hello? ... "as a service".
My advice is unless someone cares enough to write you a life-changing check ... stay away from it.