Most suitable solution for a SaaS-like platform

Hello everyone, specially those who are considered experts here. (Thank you, @Steve @MultiTech @Fabian_Weller @SkrOYC @Rifad @Suvrutt_Gurjar @WillowMobileSys @dbaum )

I am currently building a SaaS-like training platform here in Appsheet. For the most part, this platform fits my needs in terms of features. Now, in terms of scaling and managing users, there's quite a few bottlenecks. For that reason, I present here the structure that my platform would need.

In this platform, each B2B client will have its own app, with its clients. Now, I know I can't let them handle the user management, unless I teach how to access Appsheet as a non-editor, and how to add users from there.

In terms of users, my average customers have between 5 to 50 users at the same time. This would be quite stable, unless they grow rapidly on their respective services.

The ideal developing scenario would be to have a main app where I develop, and then each app from my customers with a different database each, to make sure there's no data where it doesn't belong. I would have a stable version on each one of these apps for my customers, so they don't have any problem with updates. Whenever I would have to update the apps, I would pick a late time during the weekend to apply these changes. I am worried if the updating system across apps would work this way.

Lastly, about pricing, the available platforms in the market for this purpose start at 200โ‚ฌ/month for clients. No matter how many users. With Appsheet's current pricing structure, I can't quite figure out what would fit my needs, and if it'd match my budget requirements to not be off-market.

I hope some of you can help me out. I really want to keep using Appsheet, after almost 3 years here.

Thank you,
Matรญas

0 21 1,128
21 REPLIES 21

One quick question firat as you didn't mention.. how many customers do you have?

I expect from 5 to 10 from here to January ๐Ÿ™‚

To clarify, I call customers to those trainers who pay me. Not the total users. Each trainer has their own client base.

Basically, if my client (trainer) has its own app, and this trainer manages around 20 clients, the total number of users would 22. And that's an average case.

Thanks!!

If you have 10 customers, and their 22 users, you would have 220 app users. When comparing to your 200โ‚ฌ, the app with AppSheet would be much higher.

Exactly, which is one of the reason I am posting my issue. Shouldn't there be a custom way of doing this? 20 euros/month/user makes it unscalable for a SaaS because of the unflexible pricing. We'd be at 440 euros per client if their app has 22 users. Not to mention that they cannot manage their users independently. Or not in an ideal way.

If there's no chance of doing it any other way, I guess I'll stick with Appsheet for validation, and seek for investment to step away from no-code.

Are you saying the price will be 200โ‚ฌ per customer? If that's the case, then one customer (22 users) will have smaller cost. In my example, I thought you were discussing 200โ‚ฌ for all of your customers and users.

Sorry for the misunderstanding. I meant that other SaaS in the market, for a similar feature-set, cost to a single B2B client, around 200โ‚ฌ. Therefore, I want my solution to be around those numbers. Which is why the scenario where I pay 20โ‚ฌ per user, per month, would not be suitable for my average customer. Basically, for each customer I would have to pay 440โ‚ฌ, in the case of their app having 22 users, including me and him.

Anyway, @MultiTech just mentioned what I was looking for. This concept of "Collection of users".

Thanks!

Lesser Tier?

  • 20/month is the cost for the highest license, but depending on what you're doing and how you're utilizing the platform - you might not need that high of a license.
  • From the looks of what you've said so far, you might be able to use a 10/month license; would things be scalable at that price point?

External Users

  • When you've got an enterprise license, one of the additional elements you can add on is a collection of "external user" licenses.
  • These are cheaper than regular licenses, as they are intended to be "users" not "app builders"
  • This is not something you can self-serve as of yet
  • You need to reach out to Sales - oh no! - and they can help service your account to add these special licenses.  https://support.google.com/appsheet/answer/15197435?hl=en

 

 

Thank you for your response!

The second scenario would be the most appropiate, I believe. Let's say I get the enterprise plan, and I am the only 'App Builder'. The rest of the users for this app, would be my customer and its own customer base. And they would be included in this 'collection of users'. I will contact sales and check the numbers, but it seems like the most reasonable option for now.

My only concern would be the management of this 'Collection of users'.

Thanks again!!

Steve
Platinum 5
Platinum 5

Others are more qualified to respond here, but I can share a few thoughts...

The idea of maintaining multiple copies of the app would be daunting to me, especially if the apps are complex. Over time, the differences in the apps will grow, making it increasingly difficult to apply common updates and improvements to all of them. A single shared app is easier to maintain and improve but makes it difficult to accommodate custom requests for individual clients.

If you were to pursue multiple (complex) apps, I'd think data source partitioning would be essential to avoid the headache and potential risk of reconfiguring client-specific tables for each app. Data source partitioning is an enterprise feature.

If you build your own user-management framework within the app, you wouldn't need to give clients access to the app editor to manage users. But implementing a robust, secure user-management framework in the app is not at all easy. And this approach would also expose you to the license costs of non- or ex-users connecting to the app.

Can you give us an idea how complex your apps are or expect them to become?

Thank you for the fast response, Steve.

To clarify: all of the apps are exactly the same. They just have different branding. They don't need to be different in features. That's why I mentioned the updating system.

My platform is complex, considering Appsheets specifications or limitations, but not too complex.

I have dynamic filtering, dynamic dashboards, automations, dynamic displays depending on user roles and my own user settings based off LOOKUP() formulas.


@thematgallery wrote:

all of the apps are exactly the same. They just have different branding


Like Steve suggested, I would consider using a single multi-tenant app structure while employing the "Current User" system to filter data, branding, and functionality for each client. This approach can provide several advantages:

  1. Centralized Development and Updates: Having a single app to maintain means that any updates to your platform can be pushed out immediately to all clients, reducing the overhead of weekend update cycles.
  2. Dynamic Data Segmentation: Using dynamic security filters based on the "Current User" data, you can ensure that each client has access only to their data, preventing any overlaps.
  3. Scale and Efficiency: A multi-tenant structure allows your app to scale more efficiently as new clients are added simply by configuring their access within the same system, without needing to clone the entire app.


MultiTech_0-1730910406780.jpeg

Use a strong database solution and domain auth so that they sign in in a customer portal.

After that, it's a matter of passing the right user data from your auth to AppSheet

One question you haven't explained.. how much data are you going to have e.g. after a year? That you need to think before selecting the data provider. If the answer is "yes a lot", then the real database would be your choice as you can convert security filters to SQL query and it helps with the sync oerformance.

One thing to remind.. when using AppSheet Enterprise subscription, external users are not allowed to have the same domain than the app owner has. This is probably not the case in here, just wanted to remind.

In addition to some very insightful tips by all the colleagues, I may mention one point that is peculiar to AppSheet pricing plans of secure apps.

The pricing plans are per user and not per app.  (https://about.appsheet.com/pricing/)

 As such a pricing plan typically tends to benefit subscribers who would develop multiple apps. An organization may subscribe for its 20 employees with 20 licenses and develop any number of apps for those 20 users. 

But using a per user plan for a single app in a SaaS model may not be always economically viable option, unless

A) The app has very powerful features that allow a price point above the per user monthly  subscription cost such as  (US $ 10 or US $20) + whatever profit margin the SaaS app creator wishes to earn.

B) by using the "special licenses" that Matt mentioned, if the per user cost can be brought down considerably than the standard flat cost per user ( $ 10 or $20), then it may become economically viable SaaS.

The previous replies from this forum's terrific experts note all the key points regarding how and to what degree AppSheet can be applied to your use case.

If you're going to stick with AppSheet, I'll particularly underscore @SkrOYC's recommendation to use custom authentication, such as AWS Cognito; that's crucial to dealing with the issue of "non- or ex-users connecting to the app" that @Steve cites is relevant if you utilize AppSheet's constellation of features related to customizing user management to enable your customers to manage their own users.

Nonetheless, my main recommendation is to consider not using AppSheet. As others already noted, its feature set and pricing model are a poor fit for a SaaS use case, and making it work depends on unreliable interactions with AppSheet sales staff. There are lots of other no-code options. I use Bubble; here's a video overview of How to Build a SaaS App on Bubble that I happened to receive in my inbox yesterday.

Nice to see you posting after a while @dbaum 

Hope to  continue see your informative posts. 


@dbaum wrote:

There are lots of other no-code options.


Bubble recently published How to Choose a No-Code Platform: 23 Tools Ranked on 11 Key Factors. There's plenty to quibble with regarding the specific scores and even crucial overlooked factors, but this is a helpful high-level framework for understanding, as the title notes, "key factors" to consider.

Ha! Awesome! ๐Ÿคฃ


@dbaum wrote:

Nonetheless, my main recommendation is to consider not using AppSheet. As others already noted, its feature set and pricing model are a poor fit for a SaaS use case, and making it work depends on unreliable interactions with AppSheet sales staff. There are lots of other no-code options. I use Bubble; here's a video overview of How to Build a SaaS App on Bubble that I happened to receive in my inbox yesterday


FlutterFlow, AppSmith, GlideApps...

Hi @thematgallery 

im exploring the same situation...  do you check this..!!!

Screenshot 2024-12-19 5.04.32 PM.png

I don't have a clear vision of how to build and manage all the (coaches) and their clients (or similar use cases), but instead of looking for other alternatives, after looking a lot... Appsheet is a solution that after searching and searching, I come back to the same thing... it solves one and big problems (it solves many more, but this one is important), it is simple, functional, direct, honest... people waste a lot of time on customization's that don't add value, they go out of style and quickly try to keep the client amazed... the shell is important, but I think the back office is key... this community is really real (few ads lately, but oh well...) but since its beginnings I have spent long hours discovering that the most important thing is what is just behind the screen...

For now, I am involving more and more people to the world of Appsheet, Looker Studio, Google Sheet, Drive, Docs... with simple things but that work... and I see them happy... using the tools they have available since they use Gmail... and they didn't know... they never found out...

I would be delighted to know more about how you plan to solve your concept of Providing a solution to people who need to provide more solutions... I would love to know the problems and the proposed solutions...

I also thank everyone especially ( @Steve @MultiTech @Fabian_Weller @SkrOYC @Rifad @Suvrutt_Gurjar @WillowMobileSys @dbaum ) who has participated with their answers... I read, see and discover passion in each comment... Long live the Christmas spirit


@cristobalossa wrote:

this community is really real


โ™ฅโ™ฅโ™ฅ

Top Labels in this Space