For prototyping / experimenting purpose, would it be possible to downgrade / upgrade Apps easily ? Meaning Pro subscriptions would be tied to the account holder not Apps. This would make things more easy to manage.
My other remark would be. What happens currently to the Pro subscription if the App is deleted ? Could it be reuse to upgrade another app ?
Thank you.
Thank Jason,
Yes - privacy is a concern. In our native apps we have
I think this would be a good starting point for adding this functionality, which is sorely-needed to make many useful (citizen science) apps.
Cheers,
A.
Yes, we plan to do this. I can’t give you a timeframe. If you purchase over 5 Pro apps today, you get access to this feature.
One app, two versions User and Admin.
Before: One Pro + One Free
Now: One Pro + One Pro = Double Cost?
Sounds interesting, I have only joined today, gonna be playing around with your great tool. Is there a roadmap, wish list anywhere? [quote=“david, post:1, topic:1485”]
we have some really exciting new features coming for free and Pro apps which we’ll announce next Tuesday.
[/quote]
Agreed. From what I can find the app had to have already exceeded the 500 rows prior to the switch, not have already been created. I missed exceeding the limit by 8 hours. 
Hi David,
I appreciate everything you all are doing at Glide. The Email Whitelist is an important feature of the Glide app for security purposes. Is there anyway to keep this as a free feature?
That’s a great point. If you upgrade an app to Pro that requires an admin app, we will upgrade your admin app for free, since admin apps are a limitation of Glide. Just let me know.
Update: We no longer offer free admin apps for Pro apps. Please use a Glide Org to create admin apps, where you only pay for admin access.
Thanks,
This is the user version: https://app.ahngolf.net/
This is the admin version: https://ahngolfadmin.glideapp.io/
Hi David,
I have an app that is setup in a way that a sheet A is used to collect data, sheet B is used to do some calculations and sheet C is used to view the calculated data.
I understand Sheet B wont be counted because there is no relation via the glide platform. But…
If i add in a form button for the sheet A for collecting, will that sheet we counted into the 500 row limit?
In other words, does it only count displayed data?
I support move to find a more suitable business model to continue your great product. Is there a lower payment tier for apps that don’t really use that much data?
My app is mainly used amongst a small community of friends and doesn’t require the 25,000 limit provided by the next tier. It is a YouTube Song Queuer. The main feature of the app is well under the 500 limit. And we clear our data regularly. The only feature i had to shave off because of this is the song catalog. I’d like to bring the catalog back but I do not need the additional features in the next tier and the price is not ideal atm.
I know you need to keep the lights on. I see that some people want a great value app for free. It must be hard to figure it all out.
Perhaps also consider an unlimited feature app with a two month trial and then start charging based on tiers. If I’m running a major corporation and one of us is billing them $1k a month, I think we can absorb the $19/29/49 a month without crying too loud.
After all, I looked at the competition with AppSheet and they instantly priced me out of their market offering. Let them deal with big budget agencies while you become the hero of the masses, staying just a few dollars of cost above open source.
I too had Appsheet, and was quite shocked and very unhappy with their overly drastic jump in prices. I was offering an almost free app, but then they jumped from 10 to 50 dollars within 6 months. I said ‘absolutely not,’ and got out of there quick. Glide has been a livelihood saver. Plus they didn’t have the rich features that Glide offers.
Look at Betty Blocks, that’s even a lot more expensive 
Let’s be honest, Appsheet started cheap as well, so we don’t know for sure where Glide is heading.
Hopefully they will follow their hearts, and ours, rather than the tethered guidance of any cash-in-on-a-soon-to-implode-IPO, short-term profit-driven VC masters.
I have little doubt that Google Ventures will buy them up (as long as they appeal to the masses) who will then keep it so reasonably priced that they will decimate the current opposition. It may even become a part of GSuite.
Did I mention it uses Google Sheets and not AirTable or Excel?
The trick is to build up enough users so that the Gmen don’t just steal the idea or offer key staff a job at their new division of GSheet Apps when they run low of cash.
Continuing the discussion from Announcing changes to Free and Pro apps:
Fully understand that you need to change the pricing/feature to make your business viable.
So now, I’m trying to understand the implications of the changes. My intent had been to have a completely free to my users app but fear that the row limits would make it not possible.
So, let’s say I created an app that the items I presented users was only 400 items (rows from spreadsheets used in your app.)
Which of the following would increase the # of items/rows used in the app:
a) a user needs to sign in to use the app?
b) signed in users be able to to favorite items.
If it increases the items/rows, is this per user, per item favorited, or per type of item favorited
c) non-signed in users able to make comments
d) signed in users able to make comments
e) non-signed in users able to post pictures/images
f) signed in users able to post pciture images.
Any clarification would be appreciated.
–nelia beth scovill
a) Will not count, unless (depending on sheet structure) using whitelist, which is a pro feature anyway.
b) Will not count.
c) Will not count. Must be signed in to comment.
d) Will not count.
e) 1 row per new row added. Updating existing rows will not add to row count.
f) 1 row per new row added. Updating existing rows will not add to row count.
FEEDBACK:
makes sense if you are trying to get developer to build POCs and then pay when “the app is no longer just a POC”
hmmm… Breaks the “developer can build POC” first.
Would be great, for consistency if you allow ~30 whitelist on free apps…“we want Pro apps to simply increase these limits”
Thank you. This helps me see how much is possible with the free version!
Probably not what you want, but if you are just developing a POC, Public with Email would give you the same results as Whitelist, just without the restriction of which users have access. Everything would still function the same and could be developed the same. Once you are ready to switch to Pro, then it would only be a matter of switching from Public with Email to Whitelist.
I kind of agree on a reduced limit of whitelist emails. I was thinking more of 1-5 users, so those with personal only apps can have some level of security, or in your case, a proof of concept where they could test within a small group of users.