Using Glide for a public-facing app - concerns with user numbers

Hi folks,

I’ve been working on using Glide for a couple of internal projects here. It’s been really interesting and I’ve enjoyed working my way round the app.

We’ve got a project here which I was thinking of using Glide for. It’s a public membership website which has details for approximately 1000 people stored on it. We’ve advised the client to shift this to a CRM for better security - their reasoning against having done this already is that they’ve never been able to find a CRM which offers the amount of flexibility they need.

I’m tinkering with a proof of concept here but the big hole right now is the user numbers. Maker plans allow infinite personal users, while team plans allow up to 20 of any kind of user. With this number of users, there’s bound to be a proportion of them who have personal domains or work-only email addresses.

Has anyone come across this sort of issue before, and does anyone have any tips for dealing with it? One way would just be to force people to sign in with a Gmail or similar account, but it feels pretty restrictive.

1 Like

I have the same issue currently.

I discussed this with Matt in another thread, I don’t think there’s a good way for you to create customer-facing apps to scale in Glide now, unless you can digest the cost of more expensive plans, which isn’t the case for most people.

1 Like

And 1000 users need to sign in? If so, you can contact Glide sales team on their website.

I keep holding out to hear a different answer, as I would like to just stick with Glide, but this will basically force me to at least try out bubble or caspio or both.

I’m not sure if they’re for sure better for customer facing apps, but from the outside they dont seem to cap users.

I’m still hoping Glide will find a better way to cap the users (like capping the number of users with the same domain), which would allow for customer facing apps.

1 Like