In my case, I will reach $1k/mo with only 100 users.
I wouldn’t qualify this as highly active.
I understand that I’m pushing a bit the limits of Glide with the patterns I’m using.
I’d easily imagine that a vast majority of the created apps will be much simpler.
I’d be happy to pay thousands for an highly active apps.
But currently it would be more tens of thousands.
The logical choice is therefore to invest in a technology that is cheaper to scale as soon as we get traction.
Once again, it just felt like a missed opportunity.
Hi David, as it’s been pointed out in other posts, and in one of the “wish list” items, if an app takes advantage of placeholders for menus, etc. (some of the user interface things that make an app easy to use), as well as a whole host of other tracking devices (which items a person has looked at, or taken action on, etc.) – updates add up quickly. A session column that is user-specific and only lives on the person’s device and does not need to be in the database, per se, would really stop this issue.
As you can see, I only have 4 public users, but the app that has the most updates only has two active users! I’m on target to use up all 25,000 updates by the end of the month with only 2 users actively using the app. And I have already gotten rid of a lot of the USC updates – which I did after the new update quota was put in place.
By the way, this is a READ-ONLY app, in that all the items are entered by me in the Builder, which does not count toward the update count.
I know this is not a business and not your main concern, but I know other nocode solutions while mainly targeting business, also make provisions for others to use the Apps in a productive way. After all, it’s primarily those types of users that excitedly spread the word about Glide.
Session columns would solve this problem while not increasing costs to Glide!
Well, of course I implemented things from various video tutorials on how to better the user experience – so I have buttons that show different things instead of dividing everything up into tabs – in other words, everything can be on one tab and keeps track of the user’s selection.
In other areas, the best way to equate it would be a ‘task management system’ where I might have 10 tasks, and need to check each one off each day as completed.
There are various “reminders” that pop up each day, and we need to keep track of when they are dismissed, etc.
virtually all of the edits / updates are the result of things that could be kept track of per user in a session variable that never gets stored in the database.
But all of these techniques I have adopted because of tutorials given by experts in Glide, and the initial request for session columns was made by an expert (not me).
I have seen posts from several experts stating that “this technology is essential moving forward”.
Frankly, it seems to be very low on Glide’s priority list. Not really sure why. Again, it’s not just me.
I’d like to add that there are plenty of actions that use 1 update that are highly valuable whereas others are not.
For example, a switch, Increment or checkbox is not worth $0.01 every time it’s used and can add up quite quickly, whereas a form definitely is worth $0.01. Its the little things that get quite expensive.
Ok, so, how do you get to $1k/mo with 100 active users? Your users are doing 25+ quizzes per month? How much are these users and quizzes worth to your business?
Ok, so, how do you get to $1k/mo with 100 active users? Your users are doing 25+ quizzes per month?
More likely 15 quizzes and 5 procedures.
How much are these users and quizzes worth to your business?
Are you asking the pricing?
You get some pretty crazy things nowadays for 20$.m
ChatGPT 4, Figma, Webflow just to name a few.
Pricing is still being defined, but if the cost per user is 10$.m, the price will need to be much higher for the business to be sustainable. That would limit the reach.
Also, it would be impossible to offer a free / limited version, as you do with Glide.
Is the value of the problem we want to solve not high enough?
We want to make emergency procedure easier to run.
Yesterday, a doctor told be that he was more confident treating an “anaphylactic shock” because of the app. I believe it could help save lives.
Now, I understand that I’m not your core user.
Probably that none of the other people reacting here are actually.
They are “experts” and “ambassadors” building highly polished Glide apps, pushing the limits to offer great user experiences. We’re probably the outliers generating a lot more updates than the majority
Thanks for taking the time to discuss with us.
Please be assured that I really love Glide and my only intention is to help make it better.
Concerning your last question:
It’s an e-learning app that helps caregivers learn and practice emergency procedures. We are not an hospital, but are a software editor. We would sell the app to medical care people. The final price is not defined yet. We believe it should be around 20 and 50$ a month compare to other existing e-learning apps on the market. If the hosting cost is 10$/user, it won’t leave enough room to build a sustainable business. We need to support other costs too.
As of now, my plan is to rebuild the app with another solution as soon as I’m done with the concept validation with Glide so this cost would only be cents/user. It felts to me like a missed opportunity for Glide. I’d rather stay longer on Glide and support an app that I love.
I could see in this thread that other makers had the same issue, since the update count explodes as soon as we use specific patterns. For me, $0.01 for a check, a switch or a step is expensive. 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. For our app, that would probably reduce from 50 updates/session to 2-5 updates/session (basically the recording of scores and reports).
This is an interesting point. Glide is putting an emphasis on making things “easy for users”. It seems like making things easy for users is costing more, making the tool more expensive.
However, as users spend time becoming Glide experts, they won’t be rewarded for their dedication. I wonder how Glide position themselves regarding short- versus long-term users. Is their target audience exclusively “non-tech” users?
It’s frustrating that you had to remove interesting interactions and make your user experience poorer to have to fit in a mould - and for 20 users. I’m not sure whether we want another limited no-code tool that only has space for “easy” features and few users.
I don’t mind the update quotas. What I wish Glide did is give access to the full API to Glide tables on all plans. Very simple reasoning - allow builders to build their apps on Glide tables exactly as they see them, without limits in terms of functionality. As the apps scale, we’ll move up the plan tiers naturally.
Also, regarding Glide API, why wouldn’t Glide offer a Search endpoint instead of Get all rows? (Unless I misunderstand how the Get All Rows endpoint would actually work).
Sure, but it’s easier to fund if it costs cents rather than dollars.
An alternative would be to do a free “read only” app, but it’s hard when navigation action can cost against the quota (the step by step or choice component).
