I just found out the hard way that when you duplicate an App, it counts as an update…
What would be the best way to have back ups of Apps that we create. Luckily I am testing all of this on the free plan otherwise imagine having to find out that Back ups are counted as updates and all the updates allocation for the month gone on just creating back up copies.
Maybe someone in the community might have a suggestion on how we can deal with this going forward because being able to have back ups of your Apps is crucial for emergency situations.
I would not use the ratio of Public Users to Updates as a proxy for how valuable each plan is. If you look at our FAQs, we recommend using Rows per Project and Users as a rule of thumb to determine which plan best suits a customer’s use case
A minority of users will be at 5,000 Public Users on Pro, which is why a simple ratio of Public Users to Updates is not a helpful heuristic
I would also not look at Rows per Project and compare with Updates because much of the data connected to a Glide project is not added by the project’s App or Page users
For example, imagine you have an App to manage inventory. Let’s say you add 5,000 rows of data for all your various SKUs to a Google Sheet. You then connect the sheet to Glide. None of these rows count as an Add because Adds are incurred when App or Page users add rows to your data source. When an employee interacts with the App to manage inventory, that is when an App user might then Add, Edit, or Delete rows
Note: Currently, adding, editing, and deleting rows in the Builder count as Updates, but we are planning to not count these soon
We have done an analysis of our customers’ usage patterns to determine these Updates quotas. We will continue to monitor how our customers’ usage evolves to see if any changes need to be made
Annual pricing is not currently available but will become available in the future. We will announce the discount once annual plans are live
Whitelabeling is priced at $10 per project per month. I’ll update the tooltip on the Pricing page for clarity
You can currently transfer Apps and Pages between teams, but this feature will be deprecated for Apps and Pages that are on teams with paid team plans. If your App or Page is on a team with no paid team plan, you will be able to transfer the project to other teams
Each team plan only applies to a single team. Editors are counted per team.
For example, a user that is part of 3 teams will be counted as an Editor for all 3 teams
I did a back up of 3 of my most important Apps with the Alpha team. These are the Apps i intent to upgrade to the starter package but i wanted to get a better understanding of the updates and the suitable plan to choose.
Just by doing the duplicates, i have already exceeded the allocated quota for this teams plan (Free plan)
Hmm… yes, this is not expected behavior. This might be related to the fact that Updates are currently counted (a) when you are in the Builder and (b) for unpublished projects. We are not planning on counting these Updates in the future
@kyleheney, thank you for reply. We’re using user-specific column for filters. About the country, I can’t find any plugin to dynamically detect the visitor country.
I had Pro subscription in one of my App in MyApps which I cancelled after using few days. Till now, I used to see the credit in Billing page of MyApps. I am not able to see anything here today.
Assuming I start off with starter plan and I find that I need to upgrade, is the transition a smooth one?
What I mean is if I upgrade in the middle of the month, do I pay the full subscription of the package upgraded to or do I pay a pro-rated amount of the full subscription…
When I have reached the limits of starter for example, do my Apps just stop functioning or will Glide send some form of notification that the App is close to max and therefore I should upgrade while allowing the Apps or pages to operate.
I know some of these details might not be available but maybe something to think about if it had not yet been deliberated on.
Thanks
I appreciate you getting back to me, David. Just curious why project transfers are being deprecated on these new team plans? I could see not allowing transfers between accounts, but what’s the reason projects can’t be shared between teams on the same account? Thx
Do you know how many “Sheet Edits” your App or Page previously averaged per month? This is a proxy for Syncs, which tends to be the bulk of a team’s Updates. If you averaged below 2,500 per month, the Starter plan may work for you. If that’s not enough Updates, you may still prefer to purchase additional Updates on the Starter plan than upgrading to the Pro plan
We will be offering discounts to existing customers, so you may find that a discounted Pro plan suits your needs
I’ll DM you to get more details since I can look at your App or Page’s historical Updates usage
One thing to keep in mind is that Editors are part of Teams. This is different than thinking of Teams belonging to Editors
Because of this ordering structure, it is complicated for our backend to transfer Apps and Pages across Teams (regardless if there is an Editor that belongs to both teams) as it can result in errors for the projects being transferred as they will need to be compliant with the team plan of the new team
Let me get back to you on proration as I will need to double-check exactly how the new team plans will handle cancellations and subsequent upgrades
Regarding quotas, you will receive an email letting you know when you are approaching your quota(s). We are in the process of implementing (a) Overages for Updates to allow customers to purchase more than what is included in their plans and (b) the enforcement mechanism for when teams go over their Updates quota
For now, you will not need to worry that your Apps or Pages will stop functioning if you were to go over your team’s Updates quota. However, teams that go significantly above their teams’ quotas will be reached out to by a Glide team member
Our general principle in enforcing Updates is to be generous to our customers, so you can expect things like a grace period for the first time a team goes over their quota, explicit opt-in for Overages, and a user-friendly enforcement mechanism when a team is over their quota