I have commissioned a team of Glide official developers to build the app which i am currently using. Everything works (more or less) fine except for the consumption of updates that is way too large! I consume about 5k-7k updates per day which are mainly Glide API updates.
The problem is that there is no clear way to understand exactly how many updates each feature is consuming hence I cannot evaluate the cost-benefit of each feature.
I am personally not a fan of Glide’s pricing because some features which consume updates are a “nice to have” while other features are a “must have” but the cost is the same. As a user I would have preferred a classic software pricing model based on users and glide features.
Glide wants businesses to use their software a build more and more complex/interesting apps. Business cannot predict the cost of this due to Glide’s unforecastable pricing model. Developments in Glide can hence become “update driven” since updates influence costs. This means that businesses cannot unleash their imagination on the features they can build because there is a constant pressure of too many updates = too many costs.
Other aspect to consider is that nowadays business are always more interconnected with the outside world. This means that there is an increasing importance in integrations with third party software and data from external business sources. All of this can easily translate in the need of updates hence of higher Glide bills! I am sure Glide knows what they’re are doing but I really don’t think this pricing model is a business friendly one, and the fact they target business to use Glide as their tool makes me think…
I have built an integration between Glide and my hotel’s property management system. This is consuming many updates and makes Glide uncompetitive compared to other hotel software out there which do more or less the same thing at a fixed budgetable price.
Any solutions on how to breakdown the update costs per feature before I buy existing off the shelf software solutions?
On Glide’s paid plans (team+), it rarely makes sense to build a single internal business app to replicate a SaaS software that already exists. It makes sense to use Glide on these plans to build many internal applications that preferably are tailored to the internal processes of the business (the SaaS software cannot do that). Reinventing one existing wheel is fun and tempting technically, but oftentimes doesn’t make sense from a budget perspective.
That’s exactly what I have done… i built many internal tools in 1 app, they are tailored to internal processes, of course, as you say. Otherwise I would have bought an off the shelf Saas.
The points is that hotels are hotels, restaurants are restaurants, gyms are gyms etc. hence their main needs will be similar and existing dedicated SaaS will already exists for those needs… customization and tailored features are most likely “nice to have” and never a “must have”… if it’s a “must have” there is always a SaaS to cover that need…
When I started building with Glide the pricing was different and the cost-benefit of having a customized app with tailored features was good. I spent maybe around €20k in Glide developments and then Glide changed their pricing to “the more dynamic your app is the more you pay”.
This has changed the cost-benefit ratio… going back I would have surely gone native or maybe would have chosen solutions such as Glide. Other option would have been the one to choose off the shelf SaaS renouncing to the customizations and tailored developments that cannot be made with a SaaS solution.
As I said, 99% of the times, if it’s a feature that only your hotel/bar/agency wants it’s most likely to be “a nice to have” and not “a must have…”
I have, but a discount does not solve an unbudgetable pricing model, and as a business manager i need to budget expenses and make cost-benefit driven decisions.
As mentioned in this thread Glide offers the possibility to have “nice to have tailored features” which are also more price sensitive. (Must have features for each industry always have a dedicated existing off the shelf SaaS in the market)
Usually software pricing is per users because there is a direct correlation between number of users utilizing a software and the outcome in terms of productivity. Also softwares usually price per features for the same reason: the more the features, the more value is delivered hence the more the cost.
With Glide it’s different, an increase in the number of updates does not necessarily increase the value and productivity to the business but increases the costs…
PS. In my modest opinion, the fact that Glide has many businesses which use the current pricing model does not mean it’s an optimal pricing model for businesses and does not mean they are necessarily happy with it. Also if Glide wants to reach 1 billion creators maybe it’s the case to target both the small sized bakery to the medium sized restaurant to the huge real estate company and a forecastable, certain and clear pricing model is maybe the best way to reach this since the product is already very good. Of course I am just a user and hotel expert, I know nothing about managing a software company so just sharing my thoughts here, as the CEO of Glide you surely know what’s best for Glide.
We have large businesses that prefer a pay-for-what-you-use model. We also have businesses that need more predictability in terms of how much they spend. We can support both. I reached out to you via email. Looking forward to connecting.
my consideration was that the “use” in a pay-for-what-you-use model is usually a use that is correlated to value (users and features) while with Glide it’s unfortunately not necessarily like this.
Looked at your email and unfortunately it does not solve the problem, I will get back to you by email with exhaustive context.
So we are building a new app, there are no users on the app.
Its based on Glide Tables only
It has already consumed nearly 21,000 updates in less than a month of which over 18,000 are from MAKE.
The rest are
Glide API 2500
Call API aound 150
The Make integration page mentions nothing about the updates & pricing
It would help if only we can understand how we are consuming our updates.
We use Make to add rows to our tables every time a new order is being added. (1 row for the order, 2 rows for every item in the order.)
How many rows do you think have been added to your app via Make? I suspect every time a webhook is sent to a Glide module in Make and updates a table counts as 1 update.
Yes i am expecting with every row added there is an update.
I am not sure how many have been added because the app is in testing phase
but what i know for sure is there is no clear pricing of the Make integration.
I was building a scenario in Make that would read get rows from glide then add to GLide big table & delete from Glide table
(Backing up)
and i tried to keep track of how many updates 1 run would cost… but couldn’t understand the number was in the hundreds although maybe 30 rows were fetched, added to glide big table and then deleted.
Hmm yea not sure, I only have 1 Make scenario active so I’ll have to take a closer look myself. I would expect every time for yours if it fetched 30 rows, added them and then deleted them, that 1 action would cost at least 90 updates. Did you only run it once and cost a couple hundred?
Even this, it shouldn’t logically cost 90 should it?
Fetch all rows of a table should cost 1 update. I then filter them in Make.
Then add the ones i want to backup should also cost 1 update (if I do it via API its one call api with multiple mutations)
etc…
shouldn’t be 90 should be way less. Unfortunately its in the hundreds… 300 400
Maybe i have to stop using Glide modules in Make and instead use API to get rows and delete rows and add rows… I might have read somewhere that can be way cheaper?
When Make adds 1 row, that’s 1 update. Same for add, edit, and delete.
Fetching rows from Glide uses 1 update per call, and I think it fetches 10k rows at a time (getting all rows from a 30k row table would use 3 updates).
@Darren_Murphy
Are you sure of this Darren?
According to my knowledge each API Call is 1 update
If the API call had 100 mutations, that would still be 1 update.
The max mutations allowed per call is 500.
These are API calls to Glide Tables.
Yes, I’m sure. But I’d be more than happy to be proved wrong.
I have heard that Glide are working on (or at least considering working on) a “bulk update” API extension that will consume less updates, but there is nothing confirmed about that yet.