I simply just set out to build the most robust (and indeed offline-first) foundation I could. Privacy is paramount for me and I don't want my emails piped to OpenAI.

The email scope is essentially the most restricted OAuth scope Google has, so the audit is pretty intense.

I started Marco because I finally lost patience with Apple Mail, and the email client market has a weird gap. Legacy clients look terrible and/or are not cross-platform. The good ones scan your data or cost $300+/year. And there's a graveyard of startups (Tempo, Big Mail, Caley) who built beautiful products and shut down after a year or two.

I made a few opinionated bets early on:

1. IMAP-first, not Gmail API-first. Nearly every email startup builds on the Gmail API. It's convenient, but it locks you into one provider. Marco is IMAP-native, which means it works with Gmail, Outlook, iCloud, Fastmail, custom domains, and any provider that supports IMAP.

2. Offline-first. You should be able to read, reply, delete, and organise email on a plane with no wifi. When you reconnect, everything syncs. This requirement nearly killed me. I went through WatermelonDB, Triplit, InstantDB, PowerSync, and Replicache before landing on my current approach: regular HTTP endpoints with TanStack DB and TanStack Query, using IndexedDB on web and SQLite on mobile as storage layers. I ditched "fully fledged" sync engines entirely. Turns out, for my data volumes (hundreds of thousands of entities per user), every sync engine I tried either choked on performance or added complexity I didn't need. I wrote about this journey in detail: https://marcoapp.io/blog/offline-first-landscape

3. No AI. This is intentional. Every email client launching right now leads with AI. I think most of it is noise that none of us want or need. Marco is a tool. It should be fast, reliable, and stay out of your way. No email summarisation, no smart replies, no "AI powered" anything.

The stack is React Native with Expo, Node.js backend on Railway, Postgres, Redis, S3, etc (all privately networked). Yes, a lightweight backend is needed to facilitate things like push notifications. One codebase across all frontend platforms, 100% shared code.

Marco is bootstrapped and profitable at $8/month with a 7-day free trial. 2,000+ users, all organic. No VC, no paid marketing.

Would love feedback from HN. Happy to go deep on IMAP internals, the offline-first landscape, or any of the technical decisions.

Comments URL: https://news.ycombinator.com/item?id=47519302

Points: 6

# Comments: 7

IMAP _seems_ to be a straightforward (but nasty and stateful) protocol, until you find out that every major provider ignores RFCs and does things slightly differently.

It's a hellscape.

The fix is surprisingly straightforward: own your domain, use a provider that focuses on email, and keep your client separate from your provider. Standard IMAP means all three pieces are interchangeable. If one fails, swap it out.

(I work on Marco [0], an IMAP email client. The number of people looking to decouple from Gmail/Google has been growing steadily, definitely a current trend.)

[0] https://marcoapp.io

Anyone else seeing this?

Comments URL: https://news.ycombinator.com/item?id=46765541

Points: 1

# Comments: 1

We're building a cross-provider, cross-platform email client, and literally had to build special cases for all Gmail actions:

https://marcoapp.io

The upside is that it's fast... The downside is that it's NOT IMAP!

Especially these days, you could vibe-code something an order of magnitude better within a day or two and not be locked into a single author's rat's nest of code.

https://marcoapp.io

Just curious, if this is a completely greenfield project, why IMAP instead of JMAP?

This is coming from someone who works with IMAP on a daily basis and has rightfully grown a disdain for it.