This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
I would like request an alternative or new pricing model for public users of a public app in which they can register as applicaiton end users without becoming paying developer or business users of the monthly plans like Premium, Pro, and Busisess?
I am thinking of having simple public users who will use an appsheet app for Deliveries (like fast food or take away foods), or maybe membership of a sports club. I am thinking that the app might have a few hundred or enven a few thousand simple users.
I am aware of White Label Apps:
where,
“The use of the white label option requires one of the PRO subscription plans. At least one license of Publisher PRO or 10 licenses of Secured PRO (Per user). Please consult the AppSheet pricing page for more details.”
However, the pricing page:
has not further pricing for White Label Apps.
I am looking at a user base where an end-user customer might do 1 - 3 orders a month on average, and the Restaurant and Drivers would have their own application too. They could create their own user logon name and profile just for that appsheet application.
Please respond if you would like want me to clarify or eleborate further.
Thank you for your kind attention and consideration.
Instead of the current model whereby the features of the app determine the pricing model, it would be nice we could also have a new model whereby price of license is determined by the end user’s role - and therefore what features that role has access to.
To further the example already in place, I’m just going to say a GrubHub clone, a Customer ordering food, only needs access to his own personal information, a history of his orders, and be able to see food options. Overall, a fairly low level of access.
Then the Restaurants who need to manage their information, post their menus, and receive orders, need much broader access. These are people who would already paying the dev for access to some extent. These licenses would cost more.
Any progress here? I have developed a couple of apps with a pretty small monthly active user base (40-50), however I foresee an opportunity to possibly expand to 1,000+. It’s a very simple transactional app…user inputs data, dashboard shows summary results.
My alternatives: learn to code my own app and only pay for cloud storage, pay a developer to write the code and pay for cloud storage or keep paying appsheet $10/active monthly user. $10x1,000 users x 12 months… $120K can pay for a pretty damn good developer.
This is been my dilemma too. I want to create educational apps for teachers and schools but want to White label the apps and require user sign in so that I can have specific user data and restrictions. 10,000 teachers using an app for instance it would be more cost effective for me to just build the apps out right myself. If Appsheet had a more friendly pricing model for mass scale distribution it would be a shoe in. It is not clear to me if I can have user sign in for white label apps just like if they were signing in the appsheet directly. There are a lot of instances where I could Mass distribute apps but it's becoming a an issue for pricing.
Sign-in features determine whether your app can utilize "can have specific user data and restrictions" and relate very directly to which pricing plan you need.
As noted at the bottom of https://about.appsheet.com/pricing/, the pricing plan focused on "mass scale distribution" does not allow you to "require user sign in":
Publicly accessible applications that don't contain sensitive data and don't require user sign-in can be created with an AppSheet Publisher Pro subscription. These apps include the feature sets of the AppSheet Core Plan, but do not include user sign-in options or the use of security filters. Publisher Pro apps can be used by an unlimited number of users for $50/mo/app.
Try contacting AppSheet about an Enterprise plan, where there should be more flexible options for user licensing.
LinkedIn
Twitter
