This is absolutely my āConcernā as well as I posted my MVP app example yesterday. It seems this āLess for Moreā model is being driven by some new pressures for more profitability. Not mad at Glide one bit, but we just need a balance for existing customers to stay on-board. Updates are our #1 need, followed by Whitelabeling & Public User count.
My Concerns with the New Plans:
Capping my Public Signed-in with Email Users vs. current āUnlimitedā allowances
Charging additional for Whitelabelling that by default comes with a paid ProApp
Flexibility in turning on/off monthly billing per app and getting refunded for remaining unused months
Combining ALL app sheet edits together where originally āUnlimitedā in ProApp
The new pricing is very attractive the static app users, its great if your data doesnāt need to change (directories, information, listings, etcā¦) if you donāt need to worry about branding and hence unlimited app/pages with 25,000 rows per app. you can have 99 apps for $99.
It will push away the more interactive/automation apps where I think the bigger market and the real value of low-code is. The advanced apps using API/webhooks to build enterprise apps etcā¦ will find it too expensive.
I have no problem in paying for edits, but the $10/1000 is extremely expensive. A more balanced pricing scheme should look at apps, users, rows, updates e.g
$99 per month gives you:
10 apps (branded is + $10/app)
100 private users (across all apps) (plus $10 for additional 50 users)
1000 public users (across all apps) (plus $10 for additional 200 users)
50,000 edits (across all apps) (plus $10 for 10,000 edits)
20,000 rows (total across all apps) (plus $10 for additional 1000 rows )
The numbers can change, but the structure would be much fairer at pricing for fair value obtained. In the current pricing the static APPs seem to be heavily compensated.
In light of the recent comments about updates, I am guessing that most are only realising now that itās actually a limiting factor in terms of the plans. I flagged this about 6 days ago and made a suggestion to the Glide team and I am hoping they will take a serious look at it.
The ratio of Users to updates should be closely looked at and adjusted to be in line with the Free plan. For the free plan you get to have 100 Users at 1000 updates.
So to take the Starter plan in line with that then the updates should be increased to
10 000 updates (1000 Users: 10 000 updates)
Pro should be adjusted to 50 000 update
Business should be 100 000 updates.
This will be in line with the Free plan updates. This makes sense for both the business and the users. Please Glide team, consider these suggestions.
@darder I donāt understand. I thought sync was data sync between Google Sheets and glide tables. Are you suggesting the each http GET is a sync ? I donāt that is true, please expand.
Have you checked out our new Non-profit and Educator plan? The Typeform is listed in our Pricing FAQs. Direct link to Typeform here: Glide for Non-profits and Educators
This pricing was entirely our invention, and did not come from outside.
The #1 thing that drives our costs is data updates. We have two options to make our business work:
Charge per app user
Charge for app use
#1 is just a proxy for #2, and was extremely unpopular when we tested it (e.g. pay $2/month for every user of your app).
We want Glide to work as a long-term business, so at the very least, our pricing model needs to reflect our costs. Today we have many apps that cost us hundreds of dollars per month to host due to data update volume, yet they are on a $30/month plan with unlimited updates. What would you do in this situation?
We will continue to refine the model (which updates are counted, how many are included, how they are priced at volume), but I am pretty confident that this is the right structure. Ideally, the pricing model correlates to the value for customers, and we canāt find a better correlation of value than data updates.
There is a real cost for running software that updates data. We cannot pretend this cost doesnāt exist! We apologize that our traditional pricing pretended that unlimited data updates could have a fixed cost.
David I agree with you that the new updates based pricing model should be fair as it reflects your costs, but counting every single http GET as 1 sync itās crazy. In just three hours after creating a new page in the starter plan I spend more than 10% of my starter quota.
We are not charging for http GETāwe are charging for syncing every single cell in your Google Sheet, for example, which is expensive.
As @DJP said, we plan to not count updates made while working on your app in the builder (which triggers many more updates than simply using your app). This change is coming soon, and update limits are not yet enforced.
Ok thanks. That answer helps a lot. I would like you to check if http GET isnāt really counting. I made some test and in my opinion it does. At least in my Airtable integrated page.
@darder another issue here, is that Airtable (unlike Google Sheets and Excel) does not tell Glide about changes, so we have to check your Airtable base every 3 minutes while your app is running, causing 1 update every 3 minutes. Airtable is giving us access to their new Webhooks API in the coming months, so Glide will not need to check every 3 minutes, and will only perform an update when your Airtable base is actually edited and your app is running.
Your updates are increasing while you have your Airtable app open in the builder for this reason (Glide considers your app to be running).
