I’m having trouble threading the needle of the subscription plan options in a manner that meets all the needs of my new app. I offer this case study as a suggestion to AppSheet staff regarding a seemingly unaddressed business opportunity as well as to solicit any guidance from more experienced community members. The upshot is that I’m trying to find a way to obtain a subscription plan that facilitates scalability, user authentication, and access control and also has pricing that accommodates significant monthly variability in usage. This is difficult to figure out given that critical relevant points are not addressed in published documentation; that difficulty is exacerbated by the lack of responsiveness on the part of the AppSheet sales department. Here’s a summary as a case study in the difficulty of figuring this out. Large scale Use case I license my app to multiple distinct organizations, which each needs tens or potentially hundreds of thousands of rows with frequent updates from multiple (e.g., in the dozens) simultaneous users during peak usage. My understanding of relevant AppSheet features and subscription plans: I seemingly need Enterprise features, although forthcoming Core features may meet the need. As my account is currently on the Core plan, my data source is limited to spreadsheets. The prospect of database features in the Core plan is promising, but much remains to be confirmed regarding functionality, availability timeline, and pricing. I understand that with an Enterprise plan I could improve performance by partitioning data across worksheets/workbooks or migrate the data source to a cloud database, where data could also be partitioned if still necessary. User authentication and controlled access Use case My app makes use of lots of typical features that depend on user authentication. Moreover, my app is not for use by the general public but rather only by specific users authorized by the specific organizations that I license to. Those organizations need to be able to provision users just in time–especially during peak usage periods. My understanding of relevant AppSheet features and subscription plans: I seemingly need Enterprise features, although I’m not fully confident that truly enables an efficient solution for access control. The Core plan enables my app to require sign-in. However, the only way to control access seems to be for me as the app owner to manually manage users via the app sharing allowlist. That’s not tenable since it doesn't allow the organizations that use my app to provision users on demand. As a result, my app is necessarily configured to allow all signed-in users. Although I can control access to functionality and data by maintaining a users table and matching to user emails, of course I can’t control accessing the app in first place; consequently, even if all that a user can access in the app is a “No Access” view that I created for unauthorized users, such users seemingly would still count in the tally that AppSheet uses for billing. An Enterprise plan of course also enables my app to require sign-in. Further, I infer from articles and community posts about AWS Cognito and Google Cloud Identity that it might be possible to establish a way for my licensee organizations to in effect manage their necessary allowlists via some mechanism I set up for them to do so based on one of those cloud identity services–although this point is definitely murky to me. Usage variability Use case Each organization that uses my app may have just a few users in some months but need dozens of users in other months. Also, organizations’ need for my app is tied to cyclical activities that involve a peak usage period of a few months and then perhaps no usage at all for several months or even more than a year. My understanding of relevant AppSheet features and subscription plans: I need the monthly license flexibility available in the Core plan and it’s unclear whether such flexibility is available in an Enterprise plan--and there’s not a reliable way to get that clarified. On the Core plan I can specify how many user licenses I need each month. Ideally, AppSheet would bill me for the actual number of users in a given month; but, in the absence of that convenience, I can at least pay for my anticipated number of users month by month. I don’t know what the precise usage and billing parameters are of any Enterprise plan since the information is not published and I’ve not received direct responses despite multiple inquiries via the Contact Sales function on the pricing page and directly to sales@appsheet.com. As an aside in a response to other questions, someone from AppSheet did comment to me their understanding that Enterprise “subscriptions are purchased annually and do not provide a way to reduce your subscription throughout your service term”. In addition, I’ve observed other community members reference that Enterprise plans cost $20/user/month and require a minimum of 20 licenses per month. In contrast, there’s an AppSheet Manage Your Plan page (with a very confusing layout) that suggests there is plenty of flexibility to accommodate variable usage; even more encouragingly, there are replies in community threads from AppSheet representatives explicitly offering flexibility and instructing posters to contact sales. Although I don’t know the accuracy of that mostly second-hand information nor what flexibility there is within any official parameters, based on the information I’ve found it seems that upgrading from Core to Enterprise may indeed represent an enormous threshold that could prevent many accounts from paying more than Core costs because they can’t pay as much as Enterprise costs. Paying an Enterprise price of $20 monthly per user for a full year for even a minimum of 20 users ($4800) is already more than I can recover in the pricing to my customers since they don’t need the app all year; paying that price for a full year for the number of users my app has in its peak month would be orders of magnitude more. While setting my account to be billed per app rather than per user would seem like a helpful approach, that’s not feasible given that I need to authenticate users and control access.
... View more