My cofounder and I recently decided against building an email sign in flow for our users. Our website, Kapwing, relies entirely on Google and Facebook OAuth.

In my opinion, too many startups unnecessarily build email sign in into their MVP. Although every product has different requirements, I think that, in general, founders should ditch email auth in favor of Google and Facebook Authentication. In this article, I'll explain how we made the decision and why for other early-stage tech entrepreneurs.

Background

Eric and I both worked as product managers on Google’s Identity team before founding our online image and video editing company, Kapwing, 18 months ago. At Google, we learned a ton about the complexities of sign in/ sign up at scale and worked with a senior engineering team managing billions of daily sign ins.

In 2017, we started Kapwing by building and launching the MVP ourselves. On Kapwing, users can create things without signing in. However, users must sign in to save their creations, remove the “Kapwing” watermark, and subscribe to our premium plan. Since we launched in October 2017, about 370,000 people have created Kapwing accounts and tens of thousands of daily active users (most of which don’t sign in) use the website everyday.

Kapwing's sign in modal

Unlike consumer websites like Netflix, Spotify, Squarespace, Twitter, Tumblr, Pinterest, MailChimp, Canva, and many others, Kapwing has never supported sign in with email. Users must use Google or Facebook OAuth to authenticate and get access to their account.

Why We Ditched Email Sign In

At first, when my cofounder and I were bootstrapping, we skipped email sign in as an MVP short-cut, a feature we planned to build later but didn’t have time for up front. Fast forward 16 months. Now, we had a team of 7, hundreds of thousands of active users, and seed money in the bank. But we still don’t have email sign in. In fact, we recently made the decision not to implement it at all.

I think that most startups in 2019 shouldn’t implement email sign in until they have a corporate customer that requires custom SAML sign in or until they have millions of users and hundreds of engineers. Google and Facebook sign in are sufficient to serve users and avoid a huge amount of engineering headache.

Here’s the three reasons why:

1) Email Sign In == Shared Accounts

The real reason consumers want email sign in is because they want to share their accounts with someone else. For Kapwing, nearly every user who has requested email sign in has hinted at or mentioned a shared credential. Here’s one email I got this morning:

About two months ago, I attended a growth round table with Josh Yang, the Growth Lead at YouTube TV. He spoke about how shared accounts - multiple people signing in to one account with the same credentials - have haunted other streaming sites like Netflix and HBO, whereas YouTubeTV has benefited from a close integration with Google Accounts.

Josh's point: When a platform requires Google sign in, consumers are much more likely to use their “true identity” and are less likely to share passwords. As a result, the YouTubeTV platform avoids lost revenue from shared subscriptions and has a better pitch when dealing with content partners.

Of course, the right way to avoid shared subscriptions is to support personalized features such that the user has an incentive not to share, like Slack or Figma. Although we're working on it, Kapwing does not yet have collaboration or group/team features. In the meantime, we certainly don’t want individuals to share subscriptions as it means we are less able to add multi-user functionality in the future. Plus, we make less money than if each individual subscribed separately.

Takeaway: With email sign in, it’s much easier for users to share accounts. If you have a subscription product, that means you’re losing money.

2) Email Sign In Is A Huge Engineering Effort

Two input boxes, a little encryption, and PRESTO: you have a sign in form, right? Wrong. Sign in and authentication is way more complicated than just managing a login box. Here’s a list of flows and user experiences you need to build or at least consider when adding an auth flow:

• Sign In
• Sign up: How do you create a new account from an email address?
• Password recovery: What if you forget your credentials?
• Email verification and validation: How do you ensure that someone’s email is real and that it actually belongs to them?
• Changing email and password: How do people change their email address or password, in case one of those credentials is stolen?
• Disavowal: If someone new owns an email address and wants to un-link their account from that email address, how do they disavow it without signing in?
• Age screen: How do you ensure you’re not collecting data on someone younger than 13 (violates COPPA regulations)?
• 2SV: Everyone knows that passwords are unsafe and easy to phish. Can you protect user’s private data with extra protection?
• Abuse: How do you protect your servers and database from DOS attacks or brute force attempts from bad actors?

Google and Facebook have entire teams dedicated to these issues, so startups can inherit this work instead of reinventing the wheel. Don’t underestimate the engineering effort that goes into a robust identity system. If you’re just getting started, email sign in shouldn’t be in the MVP.

Beautiful business or huge headache?

And it's not just engineering cost. Identity bugs are very severe: well-meaning customers have their data stolen or they can’t access it at all. As a result, email sign in adds operational cost in handling customer sign in problems.

Takeaway: If you don’t want your fourth engineer to work full-time on accounts, integrate with OAuth instead of building your own auth system.

3) OAuth is faster, easier, and more secure for users

When I explain to other founders why Kapwing doesn’t support sign in with email, they’re surprised, even shocked. They bring up all the legacy concerns: What if users don’t use Facebook or Google? Aren’t you violating users’ privacy by asking for social data? What if it’s a business user with a different OAuth provider?

I’m going to address each of these concerns briefly.

>> What if someone doesn’t have a Google or Facebook account?

First of all, anyone can create a Facebook or Google for free. You can link it to your Hotmail, Yahoo, or AOL account so that the emails are forwarded.

Second of all, there are almost no internet users on the planet who don’t have a Google or Facebook Account. There are billions of Facebook Accounts and tens of Billions of Google Accounts. This might be a concern for some niche Services that mostly help people get on the Internet for the first time, but since our product serves social users familiar with digital media, it’s certainly not an issue for us. In tens of thousands of messages we’ve gotten from customers, I’ve never had a Kapwing user say they don’t have a Google or Facebook account.

>> Privacy concern: Not having email sign in leads to drop-off because people don’t want to link their social data
Although Kapwing requests a very limited scope of personal data from Facebook and Google, I’ll concede that consumers nonetheless feel skeptical of the “Sign In with Google” or "Facebook" button. This fear is left over from the days when the developers sent invitations to your friends and posted on your Facebook wall without users’ consent. Hopefully, this fear will go down over time as the platforms enforce stricter consent paradigms.

So it is possible that using Google and Facebook scares some users off, but using it also reduces drop off significantly by simplifying auth:

• You don’t have to fill out a long account registration form (typing is especially difficult on mobile)
• You don’t have to verify an email address.
• You don’t have to remember what username and password you used on this random site
• You (likely) don’t need to sign in at all, since most people are permanently signed in to both Google and Facebook in their primary browser.

Google and Facebook Auth turn what would have been a huge headache into one click. Most consumers are more lazy than privacy conscious, so you’ll save yourself dropoff by ditching email sign in.

Coda, a venture-backed startup that launched this year, only allows for Google sign in. The "Don't have a Google Account?" link takes you to a feedback form

>> What if it’s a business user with a different OAuth provider?
Many companies (perhaps most?) use GSuite for email, so GSuite users can still sign in with their company domain if you offer Google Auth.

We have some data at Kapwing that requiring Google or Facebook sign in does not reduce the number of users who use their professional email address. In a recent sample of Kapwing’s customer base, 32% of customers have a custom email domain and 68% have a Google, Hotmail, Yahoo, AOL, or Outlook email address. In comparison, our blog subscribe list (where users can freely enter any email) has 31% non-Gmail sign in and 69% Gmail, Hotmail, Yahoo, AOL, or Outlook. Although it’s not a perfect comparison, these numbers suggest that the domain a person uses on Google/Facebook tends to be the same as the domain where they want to get their emails.

Lastly, for growth hackers, there are some benefits to getting a user’s personal rather than professional email. It might be easier to find people on LinkedIn and Twitter when you know their personal email address. People are less likely to share their personal email address, so emails might have higher read rates. Companies can re-target ads more easily if people use their Facebook email to sign in.

Conclusion

When seeking product market fit, startup founders must rigorously prioritize features that add value for customers. Sign in does not add value in itself; it’s just an obstacle to personalization. As a result, I think that startup founders shouldn’t invest engineering effort in authentication (unless, of course, it’s central to their value prop). Rather than following the example of companies started more than a decade ago, founders should adapt to the modern world and its tech giants. Some well-- Startups can save time and focus by relying on Google and Facebook Auth.