Marco: A privacy-first, offline-first email client built on IMAP
Source: Dev.to
How it started
I switched from Android to iPhone last year and moved my custom‑domain email from Gmail to iCloud. That meant using the Apple Mail app on iOS and macOS. After a few weeks of buggy UX and discovering that Apple Mail on iOS sends emails in a different font size than on macOS (not configurable), I started looking for alternatives. I spent two weeks evaluating every email client I could find. They all fell into three buckets:
- Legacy and ugly
- Free but selling your data
- Genuinely great but £250+/year
I’d love to use Superhuman, but I can’t justify that cost for personal email. There’s a gap, and nobody seems to be filling it.
The email client graveyard
The more we researched, the more dead email startups we found—Tempo, Big Mail, Caley.io, and countless abandoned open‑source attempts. Most lasted about 1–2 years. Two things kill them:
- Building an email client is absurdly complex.
- Google’s OAuth security review for email scopes is eye‑wateringly expensive.
Why IMAP‑first matters
Almost every email startup builds on the Gmail API. It’s convenient, but it locks you into Google. We went IMAP‑first, which guarantees interoperability with essentially any email provider in the world. IMAP is also ancient, weird, and full of edge cases—fun times and a lot to learn.
The offline‑first odyssey
This is where I nearly lost my mind. We committed to full offline support early on (read, reply, delete, organise emails on a plane with no Wi‑Fi). Sounds straightforward until you realise Marco deals with hundreds of thousands of entities and 100 MB+ of data per account.
We went through five offline‑first solutions in about three months:
WatermelonDB
- Worked initially, but uses an in‑memory JS database (LokiJS) to work around IndexedDB performance issues.
- Holding a 100 MB+ database in memory is… not great.
- Maintenance has slowed down.
Triplit
- Best‑in‑class developer experience, genuinely lovely API.
- Subscriptions timed out with under 100 k entities; we crashed their server many times.
- Rooting for this team though.
InstantDB
- No TypeScript types, no sort/ordering, no webhooks.
- Queries that took 2–5 ms in WatermelonDB took 200–500 ms here.
- The product has improved a lot since; many issues appear resolved.
PowerSync
- Most mature option on paper.
- Self‑hosting requires a MongoDB replica set on top of Postgres WAL integration.
- Frontend serialises everything between threads as JSON, so rendering 50 emails took 200 ms+.
Replicache
- Finally the right fit. It’s just a KV store on top of IndexedDB—no clever relational layer, no graph model.
- Blazing fast. We built a custom in‑memory index layer on top for queries.
- Went fully open source; conceptually similar to WatermelonDB without the RAM drawbacks.
Root cause: Every offline‑first web solution is ultimately a hack on top of IndexedDB, which is just a key‑value store. Bolting a relational model onto a KV store starts cracking around 10–50 k rows, while we have millions.
Where we are now
- 2,000+ organic users
- Bootstrapped (no VC)
- Runs on iOS, macOS, and web
- Stack: React Native, Expo, TanStack DB/Query, and Postgres on the backend
- Privacy‑first: we don’t sell data, we don’t scan emails for ads
I’m a three‑time founder and former CTO. I’ve built and scaled products before, but email is genuinely the hardest domain I’ve worked in. As someone in the email community told me: “There are very few people working on email, but there are a lot of people who want someone to be working on email.”
Feel free to ask questions about IMAP, offline‑first architecture, the email client landscape, or anything else.