Right approach to building SAAS in Laravel 4

Question

Ok, so about a year ago I wrote a web app that helps organize appointments for my dads company. He now "couldn't do business without it". I have decided that I want to build a SAAS subscription model out of it and open it up to the public.

It's currently built on codeigniter and php which I do not think is a good fit for a SAAS version. I am planning on rebuiling it from scratch in laravel 4 and using stripe as a payment gateway.

My concern is how best to handle the database / application structure for more than one client. Currently, it just serves the one business and is very un-abstract and is specific to my dads companies needs. I need it to be able to handle different data depending on what the business who uses it does.

I have looked into multi-tenancy but i'm not sure this is right for this. I am thinking that a 'gmail' style approach would be better. One app / domain that after login the user will see their customised dashboard and only their data.

Before I get stuck in with the coding I need to work out how best to handle multiple 'accounts' on the one database. I do not want to create a table for each user, nor a database for each user.

I guess my question is can anybody point me in the right direction for how best to handle a monthly payment subscription in Laravel? It's not so much the code that I'm stuggling with, rather what exactly I would need to build to handle charging the customer each month and denying them access if billing failed etc.

Thanks

Answer 1

You are in for a lot of reading and a ton of work!

First of all, let's completely ignore the billing aspect of this for now — at the end of the day that portion of the application is really fairly trivial. Take a page out of 37signals Rework (page 93 and 94) and launch your product with a 30 day free trial before you even begin implementing it (you should know how to implement it by then).

Second, why do you think that "gmail" doesn't use multi-tenancy, URI structure tells nothing about the underlying database structure. I'm fairly confident they aren't cloning a database schema for every one of their customers. Therefore you've probably answered your own question — you want to implement multi-tenancy.

You're going to want to abstract your database (and application architecture), and honestly there is no better resource to help you on your way to doing that than Taylor Otwell's (creator of Laravel) book Laravel: From Apprentice To Artisan. His book is not for beginners, and by the time you're done reading it you should probably be able to answer this question for yourself.

You are not going to be creating a table or a database for each user, you aren't even going to be creating one for each organization. Instead you'll be creating abstract database structure in code, which will pull your users data out of the database.

Think about checking for permission to access an organization as another layer of user authentication. On every request you'll be checking to see if that user can access a particular organization. You'll likely also check to ensure that organization is still active (did it expire because they didn't pay?) this will again happen on every request and likely with a filter within laravel.

This really leads to the next very important factor of developing a SaaS application.

I don't know about you, but I'm paranoid, and I couldn't sleep well at night if I wasn't sure that user number 4506 couldn't see the data of an organization that he doesn't belong to. The only really good way to ensure this is through unit testing, which I'd highly suggest learning if you haven't already.

The best way to do this within Laravel 4 is to read Jeffrey Way's book Laravel Testing Decoded. This book is extremely advanced, but still easy to understand if you have a good grasp of the fundamentals.

Last but not least, the number one thing is get involved in the community — the easiest way I'd suggest doing that is idling on the #laravel IRC channel (freenode). Ask some questions, maybe answer some questions, everyone in the channel is very nice and responsive.

You are definitely in for an adventure, don't be afraid to ask questions and make mistakes. Good luck.

Answer 2

As a rough overview, I would have a clients table, and a subscriptions table. Any other data that needs storing such as contacts, or appointments, can be associated using foreign keys to the client table.

In laravel, you can use the ORM to get the currently logged in client, and then through a relationship, fetch appointments and contacts belonging to them.

There are some useful tools for laravel at cartalyst.com, including sentry and sentry-social for user auth, and integrating user accounts with facebook/google/twitter, etc.

Stripe will allow you to configure recurring payments, and will notify you via web hooks each time there is a payment attempt. you can log these in the payments table, and associate them with a user/client. you can use this to keep track of who has paid, and how recently.

Also, bear in mind that you may not want to cancel the account immediately on failed payment.

Stripe will reattempt, and it may be that your best response is after it is two or three days late, or you get an invalid card notification,to get in touch with the client and prompt them to update their payment details.

It may also be an opportunity to check when they last logged in. If it was over a month ago you can credit them with a free month, and remind them of how much your app can do for them. By doing this, you may be able to get people to continue using (and paying) for something they had forgotten they had subscribed to.