Some people prefer to have their hosting taken care of, that don't care to worry about all the sysadmin stuff, and will pay a premium for it. Others prefer to be in control of their own stuff without having to worry about some "cloud" provider.
No offense, but this seems to be the worst of both worlds:
I still have to be aware of 0-day exploits and keep my libraries patched/up-to-date, but I also have to hope that my "cloud" provider does the same (as well as not get overwhelmed if traffic spikes in the middle of the day). I guess I don't understand what problem this solves other than providing a recurring revenue mechanism for you without the benefit of relieving myself from the responsibility of server upkeep.
Updating a self-hosted CMS sometimes is a scary thing and many people don't update or update very late. We all know how bad this can be. With Bear CMS your management tools (we don't call them backend because we offer live editing) are always up-to-date because they run on our servers. You get full control of your website (write custom PHP code for example) but don't worry about securing and maintaining your DB and administrator tools.
The closest thing I've seen to this is the platforms aimed mostly at providing providing datastores for sites/apps that pull in all their dynamic content on the client side. But these have the obvious advantage to the content manager of the client side app potentially being a static page pulling in content via js or a mobile app, as opposed to an Apache server with a PHP installation that still needs patching and securing...
All I see is a bear logo and a list of cliché features. Nowhere do I get a demo of what the CMS looks like, its admin panel and limitations.
If you don't immediately present the user with a demo and a simple explanation of what the CMS itself offers (without "some buzzwords to describe our service" which a normal user of a SaaS CMS will not understand either way) you will lose the user's interest.
We think our product is perfect if you build websites for your clients and host them on different hosting accounts. The hosting company can take care of the hosting accounts and we take care of the CMS.
I would like to present you a new better solution we've developed to build websites.
The website is hosted your own server, but it's powered by our cloud services. The management tools (that's almost 95% of a typical CMS codebase) and the database are seamlessly provided by the cloud. This improves security, maintenance and helps you get new features more frequently. Also you can run custom code on your server (typically HTML, JS and CSS and now PHP). Our solution takes the best from the hosted and self-hosted worlds, and we think it's awesome.
The first problem I saw was that I didn't see anything compelling about the management tools, which is really the product you're offering.
The Grid (http://thegrid.io) provides a service for generating your site and will generate static assets for you. I believe they'll host it as well, though I haven't had a chance to use it yet. Their service has a totally compelling pitch (such that they've had 10's of thousands of pre-orders).
I currently host some sites at Dreamhost. They manage my WordPress installation for me. So, it's self-hosted in that I have complete control over the files in my account but it is also automatically managed. And the WordPress is pretty capable.
In the end, I think it boils down to "who is this for?" A total tech person could just generate a site locally with jekyll and then rsync it to their server. A non-technical person would rather use Squarespace or WordPress.com and be done with it.
So the CMS is hosted in your cloud, and the website itself is hosted where ever we want? Am I understand this correctly?
Not sure I understand the advantage of this approach. It's interesting, but at the end of the day everything is still in the cloud, and the sites are only secure as the security on your cloud environment.
That is correct. The management tools and the DB are in our cloud. All you need is a server running Apache and PHP. Some of the main advantages are:
- no DB to maintain
- much less code to run and secure
- really fast responses because all the data is cached locally
- updates comes very fast, because they are mainly in the management tools which we host and seamlessly provide to you
High availability? Separating the editing/management interface from the live website allows you to quickly "re-publish" a site if something catastrophic happens to the hosting server. My organizations uses an enterprise CMS with the same concept. Our editing interface could be down, but the live sites are still up, and vice versa.
That's correct. The interface though is not separated. The client software that is running on your server seamlessly connects to our cloud to provide you with the management tools needed. You can call it a proxy, but a much smarter one.
Your pricing is far too confusing. Keep it simple and charge more with clear packages - charge me for telephone support or priority email if you have to.
This is very interesting question and I think I will give you interesting answer about Bear CMS. The client you run on your server (that renders the website and connects to our cloud when needed) is very small because the management tools and the DB are in the cloud. This means the client can be written in almost any language. We actually plan to release such clients. What languages do you prefer?
No offense, but this seems to be the worst of both worlds:
I still have to be aware of 0-day exploits and keep my libraries patched/up-to-date, but I also have to hope that my "cloud" provider does the same (as well as not get overwhelmed if traffic spikes in the middle of the day). I guess I don't understand what problem this solves other than providing a recurring revenue mechanism for you without the benefit of relieving myself from the responsibility of server upkeep.