Ask HN: Industry standards for locking down a SAAS product to prevent abuse?
I've just finished the software side of my first SAAS product, and was wondering if there are any industry standards or pre-made solutions/API's for signing up/email recovery, managing billing to those accounts, and enabling free trials while minimizing trial-abuse (through cookies etc)?
9 comments
If you are using Ruby on Rails, you can buy a base application with a whole bunch of best practices built in, including many payment systems. This will save you much more time than the cost of the kit.
Check out http://railskits.com/saas/ for the SaaS Rails Kit
* Disclosure - I'm friends with Ben, the owner of RailsKits, and have done work for him in the past.
Check out http://railskits.com/saas/ for the SaaS Rails Kit
* Disclosure - I'm friends with Ben, the owner of RailsKits, and have done work for him in the past.
I'm surprised that this is the first of these I've seen. This is actually a really good idea.
It's been around for a few years, and I'd definitely recommend it. It's very comforting when you find yourself saying "Wait, what if I need to do refunds or dunning emails? Oh, that's already handled." I've saved many hours of development time by starting with it as a base, and would recommend it to anyone writing Rails-based SAAS.
It has a few wrinkles though, mainly from being actively developed in 2008, with mainly bugfixes and Rails 3 support coming since then. The main ones I'd highlight that tripped me up:
- Expects payment gateway authentication credentials to be stored in a YAML file in source control instead of loaded from the environment.
- A number of the controller actions trigger immediate email sending, which can cause customer-visible 500 errors if the email sending fails and is a less reliable way of making sure the email gets sent.
- Use Stripe API v1 instead of the current v2.
- A lot of the customer email templates are kind of boilerplate-y and would not win the Patrick McKenzie stamp of copywriting approval. I believe they're loaded in from the gem rather than from the app.
My main piece of advice would be to vendor the entire gem right off the bat -- you're likely going to be tweaking several different parts of it, and there's almost no active development that you'd have to incorporate.
It has a few wrinkles though, mainly from being actively developed in 2008, with mainly bugfixes and Rails 3 support coming since then. The main ones I'd highlight that tripped me up:
- Expects payment gateway authentication credentials to be stored in a YAML file in source control instead of loaded from the environment.
- A number of the controller actions trigger immediate email sending, which can cause customer-visible 500 errors if the email sending fails and is a less reliable way of making sure the email gets sent.
- Use Stripe API v1 instead of the current v2.
- A lot of the customer email templates are kind of boilerplate-y and would not win the Patrick McKenzie stamp of copywriting approval. I believe they're loaded in from the gem rather than from the app.
My main piece of advice would be to vendor the entire gem right off the bat -- you're likely going to be tweaking several different parts of it, and there's almost no active development that you'd have to incorporate.
Unfortunately I'm using PHP, but thank you! I think I'll be going with Stripe for the payment management, now just working on account management (hashing/salting passwords etc) and associating that with the accounts. I've never done this before so it's really like building two projects at once: the software, and the account/payment management system.
Find a good PHP bcrypt library and you'll be ahead of 90% of web sites with your password security. bcrypt is the current Rails best practice password hashing solution.
Stripe is good, as you'll never see credit card numbers, so you'll have no security issues to deal with in that area
Stripe is good, as you'll never see credit card numbers, so you'll have no security issues to deal with in that area
Congrats on finishing!
I'm building a SaaS product right now and finding that there aren't very many sources for finding industry standards. Non-enterprise SaaS is quite new.
That said, I think the best thing to do is wait until you spot abuse, and create measures to prevent it. Work on your analytics and reporting systems rather than trying to contrive possible service abuses.
I'm building a SaaS product right now and finding that there aren't very many sources for finding industry standards. Non-enterprise SaaS is quite new.
That said, I think the best thing to do is wait until you spot abuse, and create measures to prevent it. Work on your analytics and reporting systems rather than trying to contrive possible service abuses.
Hey thanks! Especially for the MVP, I think you're absolutely right about the abuse part. As for the login/recovery, have you had any experience with signup rates using Facebook/Twitter authentication? Reinventing the login flow seems like a bad idea to me at this point. For billing, I'm examining Recurly and Paypal Subscriptions (although I'm wary of Paypal).
I don't have experience, but I've read this : http://blog.mailchimp.com/social-login-buttons-arent-worth-i... .
I'm rolling my own signup (which is easy enough in Django), but I'd consider doing a Google login. Facebook & Twitter I wouldn't care to implement: My target audience wouldn't want to be mixing their social logins with my service.
I'm rolling my own signup (which is easy enough in Django), but I'd consider doing a Google login. Facebook & Twitter I wouldn't care to implement: My target audience wouldn't want to be mixing their social logins with my service.