Is the update quota too restrictive for more than a prototype?

Hi everyone,

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.

The commented session

Count before the session


Count after

I use some advanced patterns, but nothing crazy :

  • 2 step by step flows
  • checkboxes / options that can reset
  • tabs

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.

What do you think?

5 Likes

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).

1 Like

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.

Many people agree with you about the updates, and this is the solution, or at least partially so.

Vote HERE:

3 Likes

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.

2 Likes

Voted, thanks for the link!

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.

1 Like

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!

5 Likes

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.

1 Like

@David - Some honest feedback:

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?

1 Like

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 :man_shrugging:t3:

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?

Yes, I’m fairly certain that’s the case. But I’m sure someone will correct me if I’m wrong.

Update: @Rev - here is a quote from the docs:

2 Likes

@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.

Yes that looks to be correct, 1 update regardless of how many columns are updated at once using a single Set Column action

1 Like

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.

4 Likes

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.

Appreciate everyone’s assistance!