

Ask HN: Industry standards for locking down a SAAS product to prevent abuse? - Terpaholic

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)?
======
tomfakes
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.

~~~
tptacek
I'm surprised that this is the first of these I've seen. This is actually a
really good idea.

~~~
jplewicke
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.

------
kvnn
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.

~~~
Terpaholic
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).

~~~
kvnn
I don't have experience, but I've read this :
[http://blog.mailchimp.com/social-login-buttons-arent-
worth-i...](http://blog.mailchimp.com/social-login-buttons-arent-worth-it/) .

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.

