Like everyone else here, I love what Glide is doing, and have become spoiled by its features.
I’m glad the Pro features are being clarified. I know everyone has an opinion on the pricing model, and I guess I’m no exception…but I hope the reasoning behind this resonates.
Currently, the model is $19/app, no exceptions. I’ve read on a few other threads that exceptions are being considered, as well as pay-per-feature options for those that don’t need every Pro feature.
But my thought is more Sheet-specific, rather than App-specific. I’d like Glide to consider the possibility of charging $19/app using a unique sheet (ie. If I purchase the pro plan for an app, auxiliary apps I create based on the same sheet are included in that pricing).
Here are a couple examples of why this may be important:
-
Admin/User apps.
Although there are ways to include hidden admin rights using user-specific components (and I’m sure there are other refinements coming to this in the future (user-specific Edit/Add; whitelist tabs, etc.)), there may always be a need for a secondary app to control admin, simply because the way we want to present data to an admin is much different than to a user, and trying to cram them in to a single app can easily make an app unintuitive. One might reason “well if they need a second app that bad, they should pay an extra $19/mo for it)”…but as you know, $19/mo is already on the top of end of what many Glide users can value their app at. If a person can afford to pay $40, $60, $80/month, they might be more likely to hire a developer to make a native firebase app that they can actually release on app stores and don’t have the limitations of a web app. -
Project-specific apps
I have a use-case, where I have multiple teams of 15-20 people each, and each team has 5-10 projects assigned to them, and each project requires uploads of photos in 5 different categories. Of course, this can all be accomplished using a single app, using a “Projects” tab with user-specific data only showing the user’s team’s projects and buttons for each category to upload. But as we tried this in the field, we realized it is much more intuitive to have static tabs for each category of photo, rather than navigating into a project and using form buttons and list relations. So we created a separate app for each project, and it works beautifully. It’s intuitive for the user, and eliminates potential of human error-related issues.
Whether I have multiple apps or one, it’s the same Pro feature economy (number of image uploads, rows, etc.), so I have to choose whether to have an unintuitive and clumsy app, or being priced out of value…which again, is making me consider hiring a developer instead of using Glide…which I’d really rather not do.
True, you will have certain situations where a user will try to game the system by having unrelated data in a single sheet to get a second app for free, but I believe this will be in the minority, and any loss will be offset by the overall increase in Pro subscriptions.
(One potential way to avoid this may be to require the user to prepend the sheet name on the app name, so he will be forced to have relation between the apps)
Glide’s profits will go up, and users will have more value in their subscription without it affecting an increase in load on Glide’s resources.
There are other ways to fix this problem as well, such as a tiered subscription model (1-5 apps, 5-10, Unlimited, etc.). But that type of model is not good for people like me, who keep things organized with different Google accounts (I currently have Glide apps in 4 different accounts, divided by Personal, Secular, etc.)…so I’d either need to keep everything in the same account (which one could argue is just another way of gaming the system, depending on how you look at it), or pay for subscriptions across all accounts, which I certainly can’t afford.
The model I’m suggesting will help with the value economy of situations where resources are not increased, only number of apps.
I hope this suggestion is helpful. Either way, I hope changes come to the Pricing model very soon, and existing features stop becoming limited, as these things greatly affect how apps are set up, and its frustrating spending dozens of hours getting an app set up a certain way, getting users using the app, only having to make major changes to it after the pro features change without warning.
Footnote: I promised myself I wouldn’t use this as an outlet to vent that frustration…but I think it’s good to know you have a lot of users waiting for these pricing models to be finalized to know how to proceed on projects they already started. I also believe as a courtesy to them you should allow any apps created before the changes to not be affected by the changes, regardless of whether the data exceeded the limits by that point…Just because the data limits weren’t exceeded doesn’t mean they didn’t spend countless hours setting up the app and preparing for its use only to be blindsided by unannounced limits.
I understand you guys gotta get paid, and I’m patiently waiting for your pricing model revisions to decide how to pay you…but until then, please know that those changes last week really negatively affected me, and after spending weeks praising your company to anyone willing to hear, it got me considering going a different direction. Just saying, a little loyalty reward for early adoption will go a long way for your existing users, and keep them excited and promoting your service to other potential paying users.
Regardless, thanks for your excellent product, and I eagerly look forward to you finalizing and implementing the pricing model changes.
- what are you trying to paste?