I was wondering if other members felt like the quota limits were too restrictive to build more than a prototype with Glide as soon as the user experience is elaborate.
On our quiz / checklist app, I can count around 50 updates per session.
Since the business plan is 249$ for 25000 updates, each session will cost 50ct.
We expect 20 sessions a month per user, so it wonāt support more than 25 users. Each user will cost 10$ a month.
I also run a development company, and I could see that those limitations were scaring some clients away from this technology. They would rather invest more in something that would better scale like Flutter Flow.
Since I believe Glide wants to be more than a prototyping tech, I thought it could be useful to open this discussion here.
For your app, are you able to make it a single form, but use some creative design to hide prior and future questions and only show the current question? This would cut your updates down from 50 to 1. Just gets more complex.
But I agree, paying $0.01 per update seems expensive. I believe Glide uses Firebase. Could be interesting if we owned the backend (meaning our own Firebase) and they provide the front end (sort of like FlutterFlow).
I actually explored this possibility, but I couldnāt find a way to create a multi-step with one single form. Also, the checklist requires a relation, and relations within forms donāt work.
Maybe, a solution would be to have some kind of ālocal variablesā which wouldnāt count against the quota but wouldnāt be saved in the database.
I have asked about this in another post, and @david said that would be too complex for the users. Although you say FlutterFlow allows that?
With Appgyver, that is the only way to use the product is to first set up your Tables in Firebase. Retool, which uses all sorts of back-end databases, expects you to have your database set up first.
Those last two are certainly much more complex than Glide, and you really have to know what you are doing. But for that reason, they are more flexible.
Correct, FlutterFlow allows you to setup Firebase and incur all the associated costs. You pay them to help setup the front end. But it is much more complex than Glide IMO. I think Glide is best for someone who has zero database and coding knowledge. Flutter might be better for someone with experience, but its just easier to build with than coding it yourself.
Making app easy to build but expensive to scale feels like a dangerous model though.
Iām trying to use Glide to create a first version I can test on the field and evolve quickly.
However, with the current pricing, I know that Iāll need to move to a different solution as soon as I reach a few dozens of users. It feels like a missed opportunity for Glide.
Yes. Things have changed and now Glide is mostly targeting businesses with over 20 employees. They progressively updated their pricing to become a more B2B focused company. This means itās getting harder to build affordable MVPs, especially if they consume many updates like quiz apps. Itās too bad because they are driving away many of the small developers!
Not just small developersā¦ As you said, their target audience has seemingly changed. I have a āread-onlyā app that is a very good resource for people, but to have it with nice menus and interactive in any way, I really need access to session variables that are not stored in the database and wonāt impact the updates. I only have two active users right now (ten casual users), and the update count shows that the max active users I could have is about 20 ā and Iāve removed A LOT of the nice interactive stuff already.
Yes. I think any action stored only locally that doesnāt hit the database shouldnāt be counted as an update. Unfortunately, they do count as updates which itās making even some simple apps to become expensive to run.
It seems like youāre disconnected from your users on this one. Charging people to work around your platformās limitations and lack of built-in functionality seems so out of touch. Things that should take one step may take 3, 4 or 5 given the limitations, and now youāre limiting us further by capping these work arounds or forcing us to pay significantly more to continue using them.
Iāve spent three months building out a product that I planned to move up the Glide pricing tiers as my platform grows, however, with this new updates quota, Iām now forced to immediately start on the enterprise tier simply because Iāve had to make so many action workarounds for basic things given the limitations - and I donāt even have any users yet!
For example, I have a button that will update a number of fields (42) in one row when pressed. Given the form limitations, Iām forced to create this work around taking advantage of Set Column Values. Instead of the button press being one action, the current updates system would count that as 42 updates. I have a number of buttons that update/clear different fields throughout my app, so all it will take is less than 200 clicks and Iāve already hit the quota. Crazy, and impossible to scale.
Iām a big fan of Glide, and I had no problem paying, but charging us for using actions just so we can get our apps running basic functions seems so out of touch. Itās shifted me from looking forward to scaling with Glide to now thinking how can I build my product outside of Glide as soon as possible.
Please donāt limit us like this, please rethink this recent change or remove certain updates from counting (clear field for example). We love Glide, but the updates quota makes it a hard sell now.
Written only out of love for Glide!
Update: @Darren_Murphy has provided insights below which alleviates some concerns around the example I provided. Maybe a Mythbusting post would be beneficial to help us understand exactly how these changes impact workflows?
If thatās a single set column values action, I believe it should only count as 1 update, regardless of how many column values are changed. If itās being counted as more than 1, then Iād have to think thatās a bug
Hey Darren! Hereās an example of one of the buttons and its actions. The row still needs to exist, just needs certain fields cleared when the button is pressed - hence me not using the delete row option.
Are you suggesting that all these updates would be counted as one update and not one update per field change - ie. 19 updates in this screenshot?
@Darren_Murphy - so, no matter how many fields are being updated within the Set Column Values, itāll still only count as 1 update - great news! Thanks for sharing this.
We look at the usage activity for hundreds of thousands of Glide apps when we make decisions about pricing. Also, we have scalable pricingāyou donāt have to do Enterprise if you need more updates than are included in the Business plan.
The number of updates included with each plan is intended as a starting pointāit is not a limit on Pro or Business, where you can turn on pay-as-you go. We have customers using hundreds of thousands of updates per month, and are still saving money for their businesses.
We think paying $1k/mo for highly active Glide apps for your business is reasonable. Maybe your expectations for what you will pay, or the value of the problems you are trying to solve, are not the same as the businesses and problems weāre focused on.
Basically itās a ācallā Glide have to make every time you do a set column, increment, add row or delete row, so no matter how many fields you change, those values will still be tied to that call.
However, I think we should also notify you that if you try deleting rows from a multiple relation, then that would be counted as multiple calls.
@David - thanks for taking the time to respond! My ignorance around what constitutes as a single update vs what doesnāt is where the confusion and frustration stemmed from. Suddenly, it looked as though Glide was an impossible platform to scale with given limitations of updates. Iām sure Iām not the only one whoās made this mistake. A āmythbustingā post might be beneficial to help clear up confusion and help those who are still confused by exactly how these changes impact workflows.
