Database-related SaaS landing page feedback requested
Hi all,
Please see [https://www.modosusaas.com]. Is the messaging clear? Would you pay for this?
At this time, core functionality for PostgreSQL and MySQL has been built.
Hi all,
Please see [https://www.modosusaas.com]. Is the messaging clear? Would you pay for this?
At this time, core functionality for PostgreSQL and MySQL has been built.
Overall, looks good, but there are a few thoughts:
There's too much content. Especially text. If I'm understanding the message correctly, it's a really one: Make your database backups foolproof by verifying that they actually work (in an automated way). Maybe you have a couple of bullet points beyond that, but that's it. (Works with your current CI/CD, keeps you covered with your boss/customers/ransomware/etc., it's super easy, when was the last time you tested your DB backup?
I'd cut out the stock images and have a screen shot or wireframe, or just no imagery, it's simple enough...
Thank you for the feedback. Yes, the message is indeed what you've described. I'm hoping this is a case where the simple idea is a good idea. Will work on the landing page some more.
Looks good to me (a database dev). As someone said below, if it does continuous testing then I would highlight that. An animated GIF of it in action would be nice but I get that you're still working on MVP.
In thinking about your target demographic, I assume it is tech-savvy. That means your target demographic is OK with a bit more data and a bit less "sexy web app" look to the landing page. I would also assume your target demographic is DB admins and devs working for larger enterprise that have production databases. As a result, you might think about messaging to make it easy for that technical dev to sell their non-technical boss on the idea/cost.
I.e. "Even good developers take an hour to check and restore a database backup, this SaaS does it in 10 minutes saving 50mins or more of developer time. At $5 it's much cheaper & easier to use this SaaS.".
Finally, I bet a quick Google search will produce some DB restore horror stories from Stack Overflow and blog posts. Having a few quotes around "what can go wrong during a DB restore" will show developers things that could go wrong that they haven't thought of and will show non-technical decision makers all the things that could go wrong.
A few things/features to note:
1.) If the DB restore contains sensitive data or PII you might want to mention security and data cleaning.
2.) It would be nice to be able to explore/search the restored data/structure before restoring in production. I.e. "sometime in the last week X was dropped from the database, now I have to restore each daily backup until I figure out when it was dropped and restore the most recent backup that has it".
3.) It would be valuable if backup upload can be automated so every backup is tested and the user gets a notification/email if the integration test(s) on a given backup fails.
As far as paying for it, I wouldn't at the moment because I'm not in a large, production environment. In the past I've run a separate DB dev machine to test/run restores on. Are you thinking a subscription price or pay-per-use? Database restore is sort of like insurance, everyone hopes they never use it. So, an annual subscription may be challenging unless you are running continuous integration tests on the regular backup files.
Hope that helps,
Thank you very much for the comprehensive feedback.
Answering in reverse order, I'm thinking of subscription, but looking ahead to the time when this product has paying customers :-) churn is possible when a customer does continuous restoration testing for say 3 months, convince themselves that their backup process is good, and unsubscribe. But I will leave that for when I do have customers.
On your #1 and #3 points to note, I will write something in the landing page copy. #3 is what I do now with my own databases, and it will be part of the product. #2 could be a nice use case; currently as I am dogfooding I already know what's in the dogfood, so to speak, so I need to think through about productizing this bit...
Target demographics: I've worked in bigco IT, and I know backups in those environments are messy, and database restoration capabilities are pretty much don't ask, don't tell, pray we never need to. That segment needs serious marketing money to crack though. For later. :-) For now, I'm trying to identify the possible beachheads.
Thanks again.
Re: Don't ask don't tell backup process - It's rogue IT until you work in IT then it's just IT...
I went through a massive ransomware at a past org. I've seen them hit files but never thought of them hitting DB backup files. Two ideas I had when we went through that are:
1.) A backup server with 7 hard drives, each day a shell script runs to enable a given hard drive, run backups, and disable the hard drive again. Doing that on a loop then allows 7 days of backups that are "air gapped" from the network and thus immune from ransomware.
2.) A daemon running in the background that either identifies unauthorized file types or unauthorized processes. I.e. .docx is allowed but .enc is not allowed, as soon as the daemon sees unauth'd file types it notifies the sysadmin and/or shuts down. Or, if the daemon is looking for server processes that are unauthorized to create files it stops the process that created a file.
Those ideas would expand the ransomware prevention beyond just DBs.
I think the messaging could be a bit more clear. I'm not sure what the value prop here would be versus just testing the backups myself?
Thank you for the feedback. The value prop is continuous automated testing, similar to continuous automated unit testing of application code in agile CI/CD. I will make that clearer.
I would try to describe what it exactly does and why. I don't really like these "Don't be this, do that..". I rather see on a first sight what it's all about and not identify myself with some claims.
Otherwise it looks good, simple, clean.
Thank you for the feedback. For the "don't be the next Internet backup horror story" chunk I feel it is an appropriate "call against inaction". But I will write some more copy and do A/B testing.
Looks interesting, messaging seems clear. I've never had a database restore fail so I personally wouldn't have a need. I'm sure there are folks that have, though.
Thank you for your reply.
Defense against ransomware that scrambles data might be one use case - database can be restored, but the restored data is garbage. Having a log knowing which backup was good could be helpful. Of course, this entails doing data checks upon each restoration, which is what I do at the moment for my own data.
That sounds a little more interesting. On the surface it just sounds like you validate backups. Maybe include some sample use cases on the site?
I'll do that! Thanks for your comments!