I have a client that wants to provide a portal for their clients. It would be a hard sell to get them to upgrade from Starter to $250+ per month for 250+ clients.
As a workaround, I created a tab that is only visible to clients with a role (clients will be managed in the data source and get a role assigned) and set visibility conditions on the tabs that make up the app requiring clients to have a specific role so only clients can see them.
The result is that anyone who somehow gets the link and wants to log in (via Public with email) will see the “Uh oh!” tab only with a message telling them this isn’t for them and to visit the company website for more information.
I guess the biggest drawback is that even though random users may not see anything, data will still be downloaded to their device and they could potentially get at it if they know how. You could mitigate this risk by making liberal use of Row Owners.
The other thing that occurs to me is that you may have a bit of a chicken and egg situation when it comes to onboarding customers. That is, you will need each customer to sign in and create an account before you can assign the role to them, which means the first time they sign in they’ll see the “uh oh” screen. Then you’ll need some way to know that they’ve signed in, identify them and assign a role. Could get quite tedious and clunky.
Sure, you could have a separate “white list” sheet somewhere and match them against that. But what happens if a customer signs in using a different email address? Or what if they capitalise the first letter of their email address, or use all upper case and you’re expecting all lower case?
You might be able to get it to work, but not without jumping through a few hoops. At the end of the day, I guess it depends how much your client values the privacy of their data (and their customers data). In my view, $250 a month isn’t that much to pay, given what you get for that.
Onboarding would be okay. Clients become clients outside the app. This is like a “your account” feature but in an app. So you’d sign up to become a client etc and as part of that you’d be given a link to the app with instructions for how to sign in, including the email to use. The Uh oh! Tab includes instructions to contact your coordinator if you’re having trouble logging in.
Client data resides in a diff system and we’re using API access to grab it, transform it and do some calculations then add this to an Excel sheet.
$250 isn’t much, it’s more that the client is paying for custom integration and automation and Glide ends up being the UI for the data that is output. It’s 250 USD / month for 250 private users but they will need hundreds if not thousands of customers. It’s not where they thought they were investing $ is all.
Thanks. I think the docs are designed with Glide Apps in mind and Glide Pages settings are slightly different so it’s not as clear in this case what Public/Private users are.
One thing I’ve realised is that if I build an app for internal use and a company has more than 250 internal users (not out of the realms of possibility) then you’re automatically onto a custom pricing plan which may be prohibitive if all other features and usage is the same. @david are you able to explain why the private user count necessitates a steep increase in costs that are passed onto customers? Not saying it’s bad, everything costs, just makes it easier to explain why this is the case.
Yes–if you need hundreds of private users, we assume you are a business and want to talk to you. If we don’t make this assumption, then Glide will never work as a business.
We don’t think hundreds of dollars per month, for unlimited Apps and Pages for a company with hundreds of employees using them is very expensive, when we consider the business customers we’re building Glide for. If this seems expensive, we’d like to hear what we could add to Glide to make it worth it!
Obviously, just judging by number of private users is not perfect–maybe you’re a non-profit with a directory app for 500 volunteers, and paying $1k/mo is just unrealistic and not a good value for that. But one of our customers has 100 delivery drivers, and hundreds of employees in retail stores, using Glide to manage deliveries and inventory–to them, Glide is easily worth $10k/month. Should we just make it so they can use Glide for, say, $99/mo without ever talking to us? That would be a huge miss.
If you talk to our Sales team, we can figure out a plan that works for you.
Great info thanks.
Again I’m not objecting to the cost, or how you run Glide, it’s more being able to easily explain it to clients
I think Glide is great value which is why I’m using it.
My scenario is a single app that my client is using to provide a client portal to their clients (so many clients!)
The only factor that would push them to a custom plan is the number of users vs. utilising all the other benefits of a higher priced plan.
However, I’m sure over time we’ll build more stuff out for them and they will have multiple apps, more rows used etc.
It was more for when number of internal users is the only factor pushing them to a higher priced plan.
As a workaround I’m using row owners and allowing anyone to sign in so you’re never downloading any data that isn’t yours and I show an access denied type tab if you’re a non-client who tries to log in (not likely but just in case).
