<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Marco App</title>
    <description>The latest articles on DEV Community by Marco App (@marcoapp).</description>
    <link>https://dev.to/marcoapp</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3806741%2F0fd91ba3-76c3-44eb-aa32-9b6c1234f953.png</url>
      <title>DEV Community: Marco App</title>
      <link>https://dev.to/marcoapp</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/marcoapp"/>
    <language>en</language>
    <item>
      <title>Marco: A privacy-first, offline-first email client built on IMAP</title>
      <dc:creator>Marco App</dc:creator>
      <pubDate>Thu, 05 Mar 2026 00:04:50 +0000</pubDate>
      <link>https://dev.to/marcoapp/marco-a-privacy-first-offline-first-email-client-built-on-imap-14le</link>
      <guid>https://dev.to/marcoapp/marco-a-privacy-first-offline-first-email-client-built-on-imap-14le</guid>
      <description>&lt;p&gt;I'm Isaac. I've been building Marco (&lt;a href="https://marcoapp.io" rel="noopener noreferrer"&gt;https://marcoapp.io&lt;/a&gt;) for about a year now. It's a cross-platform email client built in React Native with Expo, and I want to share the journey because it's been one of the hardest things I've ever built.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;How it started&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;I switched from Android to iPhone last year and moved custom domain email from Gmail to iCloud. That meant actually 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 went 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, or genuinely great but £250+/year. I'd love to use Superhuman, but I can't justify that for personal email. There's a gap, and nobody seems to be filling it.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;The email client graveyard&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;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, and Google's OAuth security review for email scopes is eye-wateringly expensive.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Why IMAP-first matters&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;The offline-first odyssey&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;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 wifi). Sounds straightforward until you realise Marco deals with hundreds of thousands of entities and 100MB+ of data per account.&lt;/p&gt;

&lt;p&gt;We went through five offline-first solutions in about three months:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;WatermelonDB&lt;/strong&gt; → Worked initially, but uses an in-memory JS database (LokiJS) to work around IndexedDB performance issues. Holding your entire 100MB+ database in memory is... not great. Maintenance has slowed down too.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Triplit&lt;/strong&gt; → Best-in-class DX, genuinely lovely API. But subscriptions timed out with under 100k entities. We crashed their server many times. Rooting for this team though.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;InstantDB&lt;/strong&gt; → No TypeScript types, no sort/ordering, no webhooks. Queries that took 2-5ms in WatermelonDB took 200-500ms here. They have since improved their product a lot. I think many of these issues are now resolved.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;PowerSync&lt;/strong&gt; → Most mature option on paper, but self-hosting requires a MongoDB replica set on top of Postgres WAL integration. Their frontend serialises everything between threads as JSON, so rendering 50 emails took 200ms+.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Replicache&lt;/strong&gt; → Finally. 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. It just went fully open source too. Conceptually similar to WatermelonDB, without the RAM drawbacks.&lt;/p&gt;

&lt;p&gt;The root cause of all these problems: 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-50k rows. We have millions.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Where we are now&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Marco has 2,000+ organic users, is bootstrapped (no VC), and runs on iOS, macOS, and web. The stack is 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.&lt;/p&gt;

&lt;p&gt;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."&lt;/p&gt;

&lt;p&gt;Happy to answer questions about IMAP, offline-first architecture, the email client landscape, or anything else.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://marcoapp.io" rel="noopener noreferrer"&gt;https://marcoapp.io&lt;/a&gt;&lt;/p&gt;

</description>
      <category>reactnative</category>
      <category>javascript</category>
      <category>productivity</category>
    </item>
  </channel>
</rss>
