The reason why you see startups avoiding this model is because supporting self hosted solutions is extremely difficult as a small team and only impedes the ability to evolve your product. It's a shame, but companies shouldn't adopt products if they lack a feature requirement (data migration).
This is only the case for complicated deployment proceedures. One of my favorite pieces of software that I love updating is a project called GitBucket. It's a GitHub/BitBucket-esq site. It's simple to host and easy to use without much overhead. The deployment procedures go as follow:
1. Install JVM 8
2. Install GIT
3. Run
If you aren't running a database it defaults to the internal one. All the defaults are sane. It also supports transfering the internal DB to other systems.
The self-hosted model works but it only works for extremely... not simple... but "refined?" setup and deployment procedures. Well bugtested and thoughtout releases. (This includes backups, auto migration, user prompts at startup of dangerious proceedures).
I think that due to this forced side effect of host-your-own that it makes the option preferable. It's harder to do but it proves higher quality control standards and allows for a much much more fail-tolerant archatecture.
I think part of the problem is that for every person like you (competent DIY'er) there are N people who don't really know how to do those 3 steps, but for whatever reason (budget, fear of SaaS, etc) decide to host the thing in-house. Those are the ones that become a support nightmare.
I get the feeling that the number of not-so-competent DIY'ers far outweighs the competent ones.
All this quality control comes with a cost. If you for example start supporting external databases you probably need to support at least few of those to cover what customers are likely already running. For each database there's no single version that everybody is using, instead you have at least two versions running. 3 databases with 2 versions each means already 6 different combinations to test on. And not just the application logic, but the update procedures.
One big problem is that if something goes wrong in the customer side, debugging those issues is really time consuming. And things do go wrong. Most of the time you are probably solving issues that are not really your problems at all. Customer don't follow the installation instructions, the environment is not like it is supposed to be, customers tinker with things they are not supposed to tinker with. How do you handle this support in practise. Are your software engineers willing to spend the time on the phone, maybe with customers in different time zones. Do they have the administration expertise for those operating systems and databases the application supports so that they feel comfortable guiding customers over the phone.
Then there is the question that do you get good enough compensation for all this compared to just offering the SaaS solution. Just the additional hands-on support given to customer quickly eats your profits from the monthly fees charged from customer. All the time spend on creating installation and update procedures, testing those and giving support to customers is away from putting up new great features. On the other hand, being able to offer the on-site version can be of course a great competitive advantage.
> For each database there's no single version that everybody is using, instead you have at least two versions running. 3 databases with 2 versions each means already 6 different combinations to test on. And not just the application logic, but the update procedures
So... use an ORM? That's what we should have been doing in the first place.
> One big problem is that if something goes wrong in the customer side, debugging those issues is really time consuming. And things do go wrong. Most of the time you are probably solving issues that are not really your problems at all. Customer don't follow the installation instructions, the environment is not like it is supposed to be, customers tinker with things they are not supposed to tinker with. How do you handle this support in practise. Are your software engineers willing to spend the time on the phone, maybe with customers in different time zones. Do they have the administration expertise for those operating systems and databases the application supports so that they feel comfortable guiding customers over the phone.
Provide it as an enterprise feature. Charge 100$/hr of debugging or provide the hosting yourself. The option to self host has to be there just in case you die so you'd only switch over to self-hosted (in most cases) if the company did die but you still needed the tooling.
Also, with docker this isn't as much of an issue. Just write a docker file and boom it's up and running.
> Then there is the question that do you get good enough compensation for all this compared to just offering the SaaS solution. Just the additional hands-on support given to customer quickly eats your profits from the monthly fees charged from customer. All the time spend on creating installation and update procedures, testing those and giving support to customers is away from putting up new great features. On the other hand, being able to offer the on-site version can be of course a great competitive advantage.
If you charge 100$/hr for setup, support, and maitnence yes it's very profitable. Look at the DBA world.
