Company Email Registration Pain Point for B2C Apps

Hi Gliders!

While I understand the motivation behind email domain restrictions, it’s becoming a real pain point for my B2C app. Not all of my random ongoing clients has gmail. Sometimes customers want to register with their company email, which isn’t part of Maker…

Any thoughts on this?
Yan

1 Like

Glide can’t determine if someone creates an account using their enterprise email address for personal purposes. Generally, everyone should know that enterprise emails shouldn’t be used for personal accounts. However, for ISP customer domains, the situation is different. Glide provides an option where you can request to add specific domains to a whitelist for personal email usage.

Glide is not meant for B2C apps. Its main purpose is to create internal tools for business.

You could go with the Business Plan and have your users sign in with any email they want.

1 Like

Well, the Maker plan is designed for

  1. Prototyping: a startup and product team wanting to whip up minimal viable applications quickly to test on a decent amount of people and where the nature of the email addresses doesn’t really matter (ie. the user will accept to use their personal email address, which most people have)

  2. Schools: the end user in mind here is students and teachers, and they are all expected to have a .edu or personal email address.

  3. Communities is general: I see this as an extension of schools. A club of some sort, a local community, where people won’t mind using their personal email address.

I don’t think the Maker plan is designed for

  1. A professional community: a portal for clients or partners
  2. A B2C application for the general public

If you are using the Maker for a B2C application for the general public, then according to me you are not using Glide and the Maker plan for its intended purpose.

I think the Maker plan and its 3 intended purposes make sense and fit within the Glide ethos. Prototyping, schools and communities in general are not purely businesses (arguable), but prototyping, schools and communities can loosely be considered businesses, to me it fits.

I also think the price point of Maker is ideal for these 3 purposes, it’s accessible.

Unrelated to the above or to Glide, I don’t understand what personal and professional email addresses have anything to do with anything. The notion of personal and professional emails does not exist on the web. And it probably never will. It’s simply a made-up concept.

So while I understand why Glide is doing this in the context of their business model, it actually makes no sense. An alternative could be to not offer the Maker plan at all. I do think that offering a Maker plan, even with one aspect that makes no sense, is better than not having the Maker plan at all.

And of course, it’s not very kind of me to criticize, because I’m not offering any ideas to help.

4 Likes

This. 100% this.

I have a constructive alternative. What if Glide offered the ability to add in “professional” users in the Maker plan, and by extension, allowed unlimited “personal” users on their Business plan?

It doesn’t exactly abolish the unnatural complication of user types, but it solves the problem of mixing user types in the near term. At least until Glide moves to their next pricing structure (which I reeeaaaally hope will have a dead simple option without the need for a flow chart or a validator app to understand.)

2 Likes

Actually I do have a suggestion. But it’s not really a suggestion because everyone knows about it, including Glide of course, they know what they’re doing: pricing based on usage.

I don’t know how that type of business model works and I’m sure there are intricacies and nuances all over the place, but it would have the advantage of being simple.

Ok, so the “Maker” package is not designed for B2C usage and is for Internal business use.

With all due respect, this is kind of restrictive because not all businesses are the same or large enough to support this. I deal mostly with small businesses and groups when we can’t add staff to an app and they can’t log in that’s an issue.

All in favor of the usage pay scale, it’s a good system and deal for everyone.

Suggestions;

  • Can we get a “Entrepreneur Maker” package which would fill the gap between the Maker and Business plans? Same as a Maker but with the ability to add the app/client domain as an recognised email address.
  • A request domain addition button in the settings tab? Making it easier to find the validation information or just plain add the domain for that business/project to be recognised in addition to the already accepted Gmails, .edu and others.

Just thoughts. But this is an annoyance that detracts from a really strong product.
Thanks,
Gregs

Not sure what you imply here, because Maker is the only plan where you have unlimited personal users. It’s the best fit for B2C albeit you have restrictions in terms of email domains that can use it (personal domains - defined by Glide as “users who sign into a Glide app using a consumer email domain, such as Gmail, or an education email domain, such as .edu”).

I agree there’s no middle ground between Maker and Business, and I can’t speak for the team in terms of their business strategy, but I think that’s not the ground Glide targets at the moment.

1 Like

Hi Thinh,
This “Ok, so the “Maker” package is not designed for B2C usage and is for Internal business use.” Was a reference to an earlier members statement.
I agree it is the best fit and personally like it. The 3 app restriction is a bit of a killer but all in all it is pretty well positioned as a Small to Medium (SME) business provider solution. The issue of the boutique domain is probably the more significant especially for when providing an app solution to a client.
They go to use their main email for their business which they want their staff using for the app and they get an error. Doesn’t look very good and the “just make a new Gmail.” answer is not a great look either.
So a Maker Entrepreneur type package could possibly provide a couple more app slots and the “add safe domain to this app” button. Potentially to lessen the jump from small scale builder to full blown developer.

Just thoughts.
Thanks for getting back.
N.Gregory

1 Like