Summary: Most of my side projects have been email-based services. I believe products that use email as a mode of engagement have great benefits for users compared to app- or web-first solutions.
I’m committed to building products that use email as the primary mode of engagement, as opposed to the web or an app. Many of my side projects have been built this way—everything from daily news digests to blogging to team pulse checks.
If you're curious: Bulletyn sends custom news digests, weejur is an email-based blogging platform, and Chekkin sends team pulse surveys and anonymized results via email.
I’ve chosen to build on email because I am making products for myself first, and in my opinion, email is a tremendously user-friendly way to engage with a service.
Here are some of the benefits I've personally enjoyed as a user of email-based products:
Portability. I can consume email on whatever client works for me. I can switch clients with no disruption in my experience. Cross-platform support is completely seamless. (This is even more true if the product’s emails have reasonable plain-text alternatives to the HTML version.)
Asynchonicity. I can engage with email-based content at my leisure—it’s waiting for me in my inbox. Issues like poor connections and firewalls don’t exist.
Control. I’m used to handling a lot of email messages mixed in with other kinds of notifications. It’s easy to set up filters and review a great deal of content quickly.
Privacy. Giving out an email address feels much less compromising than a phone number, and much, much less than other forms of verification (like a drivers' license or other form of ID).
Persistence. Finding an email I received 4 years ago is pretty simple. Finding a website is harder
In addition to the upside for users, I have also experienced some benefits as a developer of email-based services:
Universality. If you build a Slack integration or an iPhone app, you’re limited to one part of the market. With email, there’s no need to make different versions of your service for different ecosystems—one solution works for everyone.
Stability. Email is an example of the Lindy effect: the longer something has been around, the longer it is likely to last in the future. It seems likely that email will still be present in 20 years, and that you’ll be able to send someone a plain text email in much the same way you can today.
Access. There’s no need to try and convince users to enable push notifications or spend more time on your website. Instead, users will have a notification system already set up for their email accounts.
Newsletters seem to have figured this out — why bother trying to get people to check back to your blog for updates, when they can just sign up to get an email when you post?
Unfortunately, for creators, building on email does come with several drawbacks when compared to apps or websites:
Mixed international adoption. Generally, in Europe and the US, most people check their email pretty regularly—but that’s not true in every part of the world. If your product has a global userbase, email alone might not cut it.
Inconsistent styling. Trying to design emails with a consistent look on every possible client is a nightmare. It’s easier the simpler you keep your styling, and plain text is no trouble at all—but that makes it harder to build a brand identity or stand out from the crowd.
Deliverability issues. Your emails might sometimes end up in a user’s spam folder, especially if you’re also sending out marketing content. This can be a big issue depending on how critical the service you are providing is.
Potential for system abuse. If you only ask for an email address at signup, it’s much easier for bad actors to create multiple accounts.
Worse analytics. Sure, you can track things like open rate and link clicks, but without Javascript, you’re out of luck for more advanced tracking (e.g. dwell time). And some email providers are cracking down on even the simplest analytics.
Complex ad integrations. There are solutions that allow you to embed display ads in your emails, but it’s definitely not as easy as throwing AdSense on a website, and it's much harder to do any sort of personalized advertising.
That big list of disadvantages makes it seem like building on email may not be worth it after all. But many of those issues can be boiled down to a simple statement: Building on email means giving up some control over your product.
My guess is that this feeling of losing control is what prevents most creators (and especially most companies) from considering email-based products and services. If you can convince people to come to your website or download your app, you get to control the entire environment and how those users relate to your product.
But on the other hand: giving up control over the product means the users are getting more control instead. In fact, some of those "disadvantages" for creators mentioned above seem like pretty big wins for the user. Fewer ads? Less tracking? Easy to create multiple accounts?
User-centered design (UCD) is a popular philosophy of product development which keeps "the user as the center of focus".
(Jeffrey Rubin, Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests, John Wiley and Sons, Inc., 1984)
The UCD approach typically involves listening to and observing users to understand their needs (both stated and unstated) and then designing products or services to best serve those needs.
Many product organizations claim to be user-centered, and the language and toolkit of UCD is pervasive in the software development industry. However, few major commercial websites seem committed enough to the UCD philosophy to actually give users more control over their experience. In fact, it seems to me that many practice something more like "company-centered design", at least for the big stuff.
What exactly is user-centered about showing ever-proliferating ads, locking up user data, using dark patterns to prevent cancellation, putting up a paywall after letting search engines index the full page, tracking users across multiple sites, or any number of other behaviors common on the web? It's hard to imagine any of these "features" being built in response to an important user need discovered in research.
I’m not saying email-based services are the panacea to fix all these problems—and as mentioned above, they involve clear tradeoffs compared to web- or app-first approaches. But I do think giving the user more control is almost by definition user-centered, and it's simple to provide an alternative front-end on the web for those who may prefer it.
In short: I choose to build on email because I believe it’s fundamentally a much more user-centered design choice. ⧈