Unpredictable billing / unbudgetable Glide costs

Hello everyone,

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?

Thanks for any suggestions and recos.

1 Like

Maybe you can use an increment action to a column somewhere in your data to indicate that an update was used for a specific feature?

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.

We have customers with close to a million updates per month. They contacted our Sales team for custom pricing.

1 Like

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…”

1 Like

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.

1 Like

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.