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