Why I Built an Email Client in 2025 as a Solo Dev

The worst idea in software

Ask any experienced developer what they would never build, and "email client" is on the short list. The protocol is forty years old. The edge cases are infinite. Google gives away a good-enough version for free. The graveyard of failed attempts is extensive and well-documented.

Tempo, Big Mail, Caley.io: all built beautiful products, attracted enthusiastic users, and shut down within a year or two. The pattern is consistent: build something impressive, discover that the email ecosystem is vastly more complex than it appeared from the outside, run out of money or motivation.

I knew all of this when I started. I built Marco anyway, because the gap in the market was too obvious to ignore.

The gap

I switched from Android to iPhone in 2024. That meant I needed an email client that worked with iCloud Mail, not just Gmail. I evaluated every option I could find.

They broke down into three categories:

• Legacy clients (Apple Mail, Thunderbird): functional but dated, with architectural limits that show up at scale.
• Privacy-questionable clients (Spark, Edison, various free apps): great features, but your email passes through their servers in ways the privacy policy permits but your instincts object to.
• Premium clients (Superhuman, Hey): genuinely good, but $25-30/month or requiring you to adopt a new email address.

There was nothing in the middle. No client that was modern, private, affordable, and worked with any email provider. That gap was the entire thesis for Marco.

The IMAP decision

The first big bet was IMAP-first development. Almost every email startup builds on the Gmail API because it is easier. You get Google's infrastructure, Google's search, Google's push notifications. The downside is you build a Gmail client, not an email client. iCloud, Fastmail, Protonmail, custom domains, all unsupported or second-class.

I chose raw IMAP because I wanted Marco to work with every email address in the world. IMAP is forty years old, it is stateful, every provider implements it differently, and there are dozens of optional extensions with inconsistent support. Building a reliable IMAP client is dramatically harder than using the Gmail API.

It was the right call. The technical difficulty is a moat. Every email startup that builds on provider APIs eventually hits a wall when users ask about non-Gmail accounts. We started on the hard side and the coverage is universal from day one.

For the gory details of what IMAP implementation actually involves, read What Most Email Clients Get Wrong About IMAP.

The offline-first rabbit hole

The second big bet was offline-first architecture. I wanted Marco to work on a plane with no wifi, not "show cached recent messages" offline, but actually work: read, write, search, organise, as if you were online.

I underestimated this by an order of magnitude. Email is not a simple app with a few hundred records. It is hundreds of thousands of messages, millions of rows in the local database, hundreds of megabytes of data. Every offline-first framework I evaluated either could not handle the scale or introduced unacceptable performance costs.

I went through WatermelonDB (in-memory database hack to work around IndexedDB performance), Triplit (crashed the server at our data volumes), InstantDB (100x slower queries than we needed), and PowerSync (JSON serialisation bottleneck in the shared worker) before landing on Replicache, a key-value sync engine that does not try to be clever about relational queries.

The full story of that journey is in Offline-First Landscape. It was the hardest technical challenge of the project and the one I am most proud of solving.

The business model

Marco costs $4/month, or $40/year. Not free with ads, not free with data selling, not $300/year like Superhuman.

I chose this price because I wanted the business model to be unambiguous. If you pay $4/month, I do not need to monetise your data, sell your attention to advertisers, or upsell you to an enterprise plan you do not need. The product is the product. The price is the price.

The email client graveyard is full of companies that tried to compete with free. Free does not work for email clients unless you are Google and your actual product is advertising. $4/month is enough to run a sustainable business. It is low enough that individual users can pay without employer approval.

What is still hard

I want to be honest about where Marco is today.

• We do not have Windows or Android apps yet. The cross-platform story is macOS, iOS, and web.
• The feature set is intentionally constrained. If you want AI drafting or calendar integration, those are not here yet.
• We are a small team. Response times for support are good but not instant.
• Some enterprise features (admin controls, SSO, compliance) are not built yet.

I would rather ship a product that does fewer things reliably than a product that promises everything and crashes when you open an attachment. The App Store review analysis I did before building Marco confirmed that users agree: they want email that works, not email that does everything.

Why I keep going

Every week, someone emails me to say that Marco fixed something that bothered them about email for years. Usually it is search reliability, or multi-account triage, or offline access on a flight. These are not glamorous features. They are infrastructure. And getting infrastructure right is what separates email clients that survive from email clients that end up in the graveyard.

If you are curious about the broader philosophy, read Email Is Not Broken. If you want to try Marco, the 7-day free trial requires no credit card.