Marco: An Introduction

Preface

This post is technical in nature, and is the beginning of a series of technical discussions about the world of email, creating Marco, and more.

Motivations Behind Marco

Like the vast majority of human beings, the three founders of Marco have been using email on a daily basis since we were in our early teens.

We've used just about everything – AOL back in the day, Yahoo, Gmail, iCloud, Outlook, Fastmail, etc.

These days, we've got one or more personal email addresses, and lots of work email addresses for various companies and positions. Typically our email workflow involves keeping a Gmail tab open for each email address we want to monitor/use that day. It's less than ideal.

Things changed for me — Isaac — when I finally succumbed to the iPhone earlier this year. Although I use OSX, I've always been a diehard Android user. After growing more and more unhappy with Google, I decided to swap everything over to Apple. That means both hardware and software. I migrated my custom domain email from being Gmail-based to iCloud-based.

In doing so, I realised that I would then need to use the Apple Mail app, as I now had a daily-use email address which was not Google-hosted.

I spent a few weeks using Apple Mail on both OSX and iOS. It's not great. The UI/UX is outdated, slow, and frankly buggy. The final straw was discovering that Apple Mail on iOS sends emails in a different font size than Apple Mail on OSX, and this setting cannot be configured — you can only change it on a per-email basis.

This kicked off a roughly two week process of evaluating all email client products available. I found that they broadly fall into three categories:

1. Legacy – functional, but lacks modern features, looks terrible, not cross-platform.

2. Questionable business model – apps that are great, but... sell your data.

3. Expensive – a handful of email apps are genuinely fantastic, but the cost is out of reach unless your employer is paying your way.

I would love to use Superhuman, but have a hard time justifying paying $300-$400/year for a personal email client.

In the end, I settled on Missive as my daily driver, as it suits my needs the best out of all available options. That said, Missive is also quite expensive outside of their free tier, and their product is fundamentally built for team collaboration and shared inboxes.

I found it shocking to discover that there was not a single email client on the market that suited my relatively common/normal needs.

There's a gap in the market, and we are filling it.

The World of Email

So we came together as three co-founders and began researching everything about email. We quickly discovered that email is weird, archaic, pretty broken, and is only actively worked on by a small group of individuals.

As a prominent figure in the "email world" said to me: "There are very few people working on email, but there are a lot of people who want someone to be working on email".

Email is about as unsexy as tech can get. It's full of all of the worst kind of software problems: endless edge cases, outdated and rigid protocols, vast quantities of data, lack of standardisation and plenty of hacks, etc.

The Email Client Graveyard

In our research, we also began to identify a very concerning pattern — we came across email startup after email startup, who had seemingly put together a beautiful and functionally-compelling product, and then closed operations after ~1-2 years.

Notable mentions in the graveyard:

• Tempo

• Big Mail

• Caley.io

These three are "for profit" attempts, and there are countless more FOSS attempts which began with enthusiasm and then were subsequently abandoned.

There are two main problems in building an email client:

1. Building an email client is insanely complex and difficult

2. Google OAuth API access for email scopes requires a $75k/year security review + pen test

Tatem is another in-progress email client project which we are keenly keeping an eye on, as their design language is beautiful. However it seems they are also blocked by Google API access, and the process to gain access can take many months and many thousands of dollars.

Learning from Past Mistakes

It became clear to us that there are many pitfalls to avoid, if we want to successfully launch a functional, useful, and beautiful cross-platform email client.

Our first major decision was to build an email product that is IMAP-first. This is the opposite of essentially all email products on the market, with the exception of Missive. Nearly all email products on the market have chosen to integrate with APIs directly, as it's much, much easier. This is why a plethora of email products only support Google/Gmail.

Taking an IMAP-first approach will guarantee interoperability with the vast majority of email addresses in the world.

Beyond that, how can a tiny team build an email app that runs on OSX, Windows, Android, iOS, and web? By following in the footsteps of Missive! After investigating and reverse-engineering their product a bit, and listening to some podcasts from the founders, it became clear that they are developing a single web application, and then wrapping it with CapacitorJs to run on native platforms.

This is the approach we are taking as well. It means we need to develop a single backend codebase, and a single frontend codebase.

With only two developers, this is the only realistic way we will be able to achieve our goal of cross-platform, cross-provider: IMAP-first backend, and universal web-app frontend.