Our startup is focused on community engagement powered by mobile and gamification. Our product is a CMS platform paired with an app. The platform allows clients to make campaigns easily via the campaign editor. The campaigns are then published on the app.
Though we'd like our business model to continue being SaaS, many clients keep asking to have their own app. What's the best way to manage these requests as we do not want to be a dev shop and would like to have everyone use the same app to the extent possible. Note: once people download the app and log in, they can use which campaigns they're a part of or the app automatically recognizes the email address and would take them to a client-branded campaign.
I see some folks answering this, I'll chime in with my thoughts and strategy.
You have to look at what the customer's requirements are -- that's critical. First and foremost, is the customer going to require their own "view" of data or better, will they need to have the code execute and retrieve data in a way in which it's unique to them -- or can all the customers view and use the application through a common view?
Then there are requirements that need to be considered around how to maintain the application and how the customer is going to use it.
With that in mind, as you know the benefits of SaaS are that you're using a common code base, making updates and changing code that ALL the customers can realize. When the customer gets up up in the morning, login, they see the new feature you added and deployed. There's no need to install something or have them do anything specific. Features and functionality are delivered to them through a Web browser.
However, this does present some problems with the idea that "each customer is different". If you have a customer base that you need to contour the application code to fit within their business, you might find that SaaS and a common code base can be not only tricky, but will be impossible to manage.
Anyway, when I build these types of systems, I ask these questions:
1. How many customers are going to use this system? - think scalability here.
2. Does the customer need a customized version of the application to succeed?
3. Is multi-currency and internationalization important?
4. Does the customer need access to their data and the database?
5. Does the customer have security rules that have restrictions on their data?
6. Does the customer use any external applications that may need to "talk" to the SaaS application
Based on the answer to these questions, determine how I would build the app.
Now, someone with a keen eye will notice I haven't mentioned the technology part yet.
There's a reason for this. The technology is actually the easy part of the equation, what you need to know before going down the path of a SaaS application is your audience and customer, then you need to ask what is the best architecture, platform and stack, etc.
To give examples:
If you're building an app that's going to service lots of customers who are benign in their use of the application and aren't concerned about the data access to their data other than through the application itself, then the "multi-tenant single DB instance apartment model (MTAM)" where you have a single database instance being shared among tenants is probably the way to go. This is no different than Basecamp or applications that are affordable but don't allow for any unique customer features -- it does what it does and that's it, nothing more, nothing less.
MTAM can be the easiest way to get a SaaS application up and running, offer you the best means of CD and probably the single easiest to deploy and maintain -- it also offers the least amount of flexibility around application customizations and scalability -- as you're using a single code base and single DB instance. Customizations to the code are "no no" and having a single database that services ALL tenants can be risky as you grow, although, this is really more of a concern on cost as we all know you can throw iron at performance fix the issue (ugh!).
Anyway, If the customers need to have code that is custom to them but you want to keep delivery consistent and ensure "CD" (Constant Delivery) of new features and updates?
You will want to go with a "multi-tenant multiple instance apartment container model".
This is where each tenant will have their own database running as an instance and also have the code running specific to them in a container. Using Docker containers to build customized containers based off the main code release branch for the customers needs will allow you to keep the benefits of SaaS but also allow for the customer to achieve their needs. When you do a release to production, each customer not only has their own database but they have a container with their custom code that's built and released for them off the branch. Of course, this is more complicated and not easy, but I'm only demonstrating that there's many flavors of SaaS that can be architected.
Hope this helps.
I agree with Mr. Gary MacDougall that you need keep in mind what customer needs are. I do understand that you was to operate it in SaaS model but whats harm in giving it to the client exclusively and charge those clients annually as license fees and make sure that software doesnt work after the expire so if they want to discontinue they can extract the data and stop using your software.
I guess the challenge is to have your client see the advantage of subscribing to your saas rather than developing in-house application to achieve the same needs. Perhaps a cost Vs objectives would be viable. However, established companies that are at corporate level normally would create their own applications.
I hope this could contribute to some thoughts on how you could convert them into full Saas subscribers for the platform.
A technical compromise would be a multi-tenant SaaS application.
Unless your clients insist on physically owning their application instance (better avoid such clients IMHO) there are straightforward ways of offering their private, watertight space on your infrastructure.
Application frameworks like Ruby on Rails (most probably others, I just happen to know RoR) have multi-tenant extension that let you tranparently connect each client to their own database through the single common application.
This way you get best of both worlds : your client sees his own private application and you only have one single physical application instance to worry about.
As a bonus, your single, centralized back-office application lets you manage all your clients.
Hope it helps :-)
An app can be just a simple interface to your system. You can white label the app and allow them to download it and have it connect to your servers. Just need to push updates. Harder because of app store rules.
If it is a web app, then even easier. Give them the ability to choose a subdomain or point a custom domain name to your application. Then allow for a table with fields related to the client with standard size logos, names, etc. In your webapp views, switch based on what company they are logged in as.
I have done this several times. It i show I run my SaaS platform for health insurance sales tldcrm.com
Thank you all for taking the time to give me food for thought, especially @Gary MacDougall for being so detailed and explicit :) The issue is more of a marketing one for the organizations/companies: they'd like people to download THEIR app, not necessarily our app that would then take them to client-specific campaigns based on their logins. Unfortunately, we're not doing a web app as that would be simpler; we're using React Native
What if you offered a separate package for ownership of the app? You can still get revenue through platform as a service. It could be modeled a one time dev fee and they get ownership. As you say you don't want to be a dev company you can outsource it. I think some documentation would be required stating it is up to them for all upgrades and such and because it is your platform you retain the right to only allow apps that meet a certain standard but if they own it the app may be serving its purpose for them and such they want to let it be. Just some thoughts.
You can try to convince the customer of the benefits of your platform, that will require some research of your existing customers, to find out what they like about your product and why they chose you.
At that point you can craft a sales plan around those benefits.
Alternatively if the customer wants their own app, then it would be wise for you to find a solution and partner with a company where you can white label their platform and provide those customers what they are looking for.
With that being said, we have such a platform. If you are interested i can give you a demo of our offering to see if it fits with you.
Let me know.
If they are willing to pay the right amount, why not !