So, Im building an app with the help of one of the GlideApp partners. I want to sell the app to the general public. I think the app is going to be a big hit and should sell well.
I have read through documentation on submitting to the template store and understand GlideApps keeps 30%.
Here is my bigger question that I can not find in the documentation.
The general public is familiar with an “App” from the Apple or Google Play store. They are NOT used to getting an account in Glideapp, purchasing a template and then trying to load it on their phone.
Is there any documentation I can point new buyers to, or has anyone created documentation/videos on this subject?
Are you attempting to sell the app for users to buy as app developers where they can modify and customize the app to their liking, or do you want to sell a subscription to use your app?
It sounds like you want to do the later and sell the use of your app. You would maintain the app and database in that case. Then you simply need to share the published url of your app and build mechanism for users to purchase the ability to unlock full use of the app.
True, this is how to install, but that is assuming you have the app in a Glide account or someone shared it with you.
Im wanting to sell an app and then have someone install and trying to determine how burdensome it is on a non-techie buyer to setup an account in GlideApp, purchase the Template and then install.
I want to sell the app and the google sheet that goes with it. I want the buyer to be able to edit the data either inside of the app or in the google sheet to make it easy for them.
Like I said, most “App Buyers” are familiar with buying from one of the App stores, but GlideApp makes it a bit more cumbersome.
But glide templates are geared towards those that intend to build and modify apps using the glide builder. It’s not meant for an end user that will simply use the app with no knowledge of how glide works.
When I download an app from the app store, I’m an end user using the app as is with whatever cloud database is already connected to the app. I’m not a developer attempting to download an app like Facebook and have full control of the code and database. I just use it as an end user.
I guess the question is, who is the intended audience for your app. Is it end users who want to just use the app, or is it developers that want to modify, customize, and have full control of the app? People who buy apps from an app store have no interest in the backend code and design of the app. They just want to use it. That is quite different from handing over all of the code and the database. If you are handing over the code and database, you better hope they know how to use glide and the glide builder.
I want users to have the app to track items. I assume I may have MANY users, like 1000+ so Im not sure how I would manage selling to users of that number of users of one app.
I think I remember reading a post from 2020 where the GlideApp team was working on a way to make this easier.
@david any thoughts on that or how to make this selling good for you and me?
I saw your other post in the other thread. I’ll partially respond to that. If you were able to publish your app to the Apple or Google app stores, the app in those stores would still refer to YOUR app and YOUR database. It would not create a “copy” that’s unique to each user every time they download it. It’s still YOUR app, and not theirs. Any changes you make to your version of the app or the database would be seen by any user that uses the app.
Glide apps are essentially websites with a web cloud database that are hosted on a central server. The database isn’t local to any user. The only way to have a database that’s unique to a user is to let them purchase a template under their own glide account.
Yes, hosting that many users under one app could be tricky. You have to consider a lot of things including the total number of rows that you would ultimately have. Glide tables are a little more forgiving than Google sheets when it comes to the shear number of rows. 25,000 rows is a soft limit, but a limit to keep in the back of your mind. Row Owners will help to control and limit access to data that is only owned by the signed in user, which will help with load for the end user and help secure their data.
I think what you wanting is to have end users that have full control of an app building interface and a database without having any knowledge of glide. You can’t have both ways though. If you are going to let end users have development abilities, they will need to having an understanding of how the development side works.
Thanks Jeff, I am working with a GlideApps recommended partner developer and we did enable user specific elements so maybe what you are proposing is the best course of action.
We will continue with some beta testing of the app with some beta users to ensure its working properly and get rid of bugs, but then we will have to investigate how to make this paywall approach happen and ensure I know how to manage that.
thanks for taking the time to help educate those of us that don’t know this area well. I know I have a good idea, and now we have a great app, but getting it monetized is the hard part!
You could also take into account that an ideal use case for a Glide app is an app for work: a business app that allows and facilitates CRUD (creation, reading, updating, deletion) of data.
Types of app for work
Internal: for employees or partners (with restricted sign-in), such as portals.
External: for customers or partners (with little to no restriction to access the app, access with email for personalization purposes), like a website that has app-like features
Should your app be a typical App Store consumer app where the user base could theoretically scale to millions, then I think you’ll have difficulty achieving this with Glide. Maybe it would work if you set up your app with no restriction to access. At low scale it would be a personal app and then the question of cost and monetization would come into question.
