This post might be buried way down of a long thread but I thought I will contribute anyway.
Introduction of a 1000 edits per month limit on free tier - what does that mean to us as developers? I have a few perspectives on that:
-
Transparency
-
Predictability
-
Vision of free tier
-
Edits in the builder also counts
-
Navigating by use of choice components
-
Form vs one-bit-change (rating, favorites, text entry component)
-
Workaround
-
Grandfathering
Predictability, transparency and the vision of the free tier is probably my biggest concern. A lot of us have started on a trip together with Glide. But it is unclear what we should expect and when. I would like to understand what kind of limitations (and possibilities) that will emerge in the future. Does it make sense to create such an app if the future looks very much different from the present. A 1000 edits per month is such a limitation. I was not able to predict that such a limitation was coming as there is no transparency in the roadmap. This brings me to the vision of the free tier. Who should use the free tier and for what? Is it just for fun, for small mvp’s - or what? As of now it seems as smaller app (less than 500 rows) with no input from the users could be a lasting free app - but next month there might be new limitations. So what is the vision of the free tier? Please let us know so we can do an informed decision whether to invest time in doing a free tier app.
The timing and the warning of a new limitation is also an issue. The limitation is put in place from one day to another. It is the time of year where a lot a people have holidays. If you need to adjust your app to comply with the new limitations, you might need to put in some extra time - but you haven’t been able to plan for that. It is actually a bit the same when Glide rolls out changes in existing functionality that alters the app significantly without giving us time to prepare for change.
Next thing concerns which functionality that constitutes “an edit”. Choice component is often used as a mean to control what should be shown in the app i.e. it is not the purpose of the choice component to set values in the sheet. But Glide cannot do such viewing selections without setting values in the sheet. Example, show only cities in western USA.
Then onto edits which actually adds data to Glide (and/or sheets). There are quite a few. If the app makes use of quick selections like ratings or favorites then the user can very quickly do a lot of edits. Thereby quickly racing to the 1000 edits limit. I have been working on an app where the user can use a number of the text input components instead of a form as this makes a nicer UX - but this will be an expensive way (number of edits wise) to do the design. This means that the designer will need to do other designs in order to keep the edits lower.
Testing the app in the Glide builder will also count towards the edit limit. So the limits isn’t only for the production app - that seems odd. As limitations are put on the free tier app workarounds will start to appear and the developer might copy the apps in order to circumvent the restriction and ending up with multiple apps in the builder. The app building experience would be worse - but possibly the same number of edits Glide will have to pay for as if the builder edits didn’t add to the total edit. The app developer that might also be put off going to the next level and buy a pro app. Maybe - just speculations.
Previously, Glide has provided grandfathering to existing apps. Have you considered that with this new limitation or have you left this idea.
To sum it up - tell us where you going so we know what to expect - and consider how restrictive you should be when doing the edit counts.