Should I vibe code
Build a cross-platform email client with read receipts, snooze, and send later
Read receipts are a tracking pixel in a personal email. Apple has pre-loaded them since 2021, so yours mostly lie.
?
Their verdict, the Newton price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Newton is running, which was the first thing worth checking: $49.99 a year, one tier, forty thousand subscribers, and a client that has now been announced dead three separate times and come back three separate times. That history is why people build their own mail clients and it is not the reason to stop reading. Look instead at the three features Newton leads with. Read receipts, on by default for every message you send, which is a tracking pixel in mail to your accountant and your mother. Send later and snooze, which need something awake at six in the morning — either your laptop lid stays open or you run a relay holding credentials to the mailbox that resets the password on everything else you own. And a button that publishes a private thread at a public URL, which in a weekend build is a UUID, no access log, and an expiry field nobody wired up. The sync engine everyone worries about is the least of it. These three are what make it somebody else's problem rather than only yours.
What actually breaks
not "if". the specific failures.
- Read receipts, in the specific sense that they keep working and keep being wrong — Apple's Mail Privacy Protection has been pre-fetching remote content through a proxy since 2021, so a good share of your 'opened at 09:14' events are a cache warming rather than a person
- The default, which is the part with a regulator attached: tracking every recipient of every message unless they opt out is the opposite of how consent is supposed to work in the EU
- Send later, the first time it matters — the lid was shut, the laptop slept, and the email you scheduled for a Monday morning went out on Tuesday afternoon or not at all
- Snooze, which is the same bet in reverse: a message you deliberately hid from yourself, held by a process that restarted
- Public share links, which in the first version are unguessable-therefore-safe, have no access log, and quietly include the attachments
- Inbox rules, the day auto-forward matches something it should not and a copy of an internal thread lands outside the company
- The IMAP or OAuth credential in your relay's database, which is the highest-value secret you own and now lives on a droplet you set up on a Sunday
- Cross-platform parity, which is where the multi-day estimate becomes a multi-month one: four clients, four notification systems, one sync protocol you invented
The thread you shared with a link back in March was a supplier negotiation, and you shared it because it was faster than forwarding — paste into Slack, done. The compose dialog had an expiry field and it defaulted to never, because that was the default you wrote and you were the only user. Nine months later the supplier's counsel is asking, politely, how a message they sent you in confidence is sitting at a public URL on a hostname with your name in it. Somebody had pasted the link into an issue tracker that turned out to be world-readable, and a crawler did the rest. There is no access log, because you never built one, so the honest answer to 'who else has read this' is that you have no idea. And the part that actually stings is jurisdictional rather than technical: there were four people on that thread and you published it on behalf of all of them.
Is that you?
the verdict is a default, not a law
- It reads and composes and does nothing else clever — no receipts, no scheduling, no sharing
- Everything runs locally against a mailbox you own, with no server holding a credential
- You keep the account restricted to a single provider you can test against properly
- You still have a working mail client installed for the weeks when yours is broken
- Read receipts are on by default, or on at all for correspondents who never agreed to be measured
- A hosted component of yours stores IMAP passwords or long-lived OAuth refresh tokens
- Anything publishes an email at a URL that does not expire and does not log access
- Auto-forwarding rules can fire without a human having reviewed what they matched
- The mailbox is a work account whose administrator would like a word about where its contents are being cached
If you build it anyway
the checklist, then the prompt that enforces it
- Make read receipts opt-in per message, off by default, and label the result honestly — 'possible open, may be a mail proxy' is the truthful string, and if that makes the feature feel useless, that is the feature telling you something true.
- Decide where scheduled sends run before you build them. On-device means being clear that a closed laptop misses the slot; server-side means a credential store, and if you are not prepared to encrypt tokens at rest with a key that is not in the same database, do not build the server version.
- Treat every credential as the crown jewels, because it is. Prefer OAuth over stored passwords, request the narrowest scope that works, and write the revocation path before the login path.
- Share links get authentication, a real expiry that is enforced server-side, an access log, and a default that is short. Attachments are excluded until you have deliberately decided otherwise.
- Auto-forward is the rule action to build last and gate hardest. Everything else is reversible; a forwarded copy of a thread is not.
- Make the local cache encrypted and make deletion actually delete. A mail client's cache is a full copy of your correspondence sitting in a directory you forget exists.
- Build against one provider until it is genuinely solid. Gmail's label model and IMAP's folder model are not the same shape, and pretending they are is how threads start disappearing.
I am building a desktop and mobile email client with read receipts, snooze and
send later. Apply these constraints and push back when I ask to cross one.
1. Credentials before features. Use OAuth with the narrowest scope that works,
never store a plaintext IMAP password, encrypt tokens at rest with a key that
is not in the same store, and implement sign-out and revocation first.
2. Read receipts are opt-in per message and off by default. Refuse to make them
global. Explain that a remote-image pixel in one-to-one mail is tracking that
the recipient never agreed to, and that under EU rules that is a consent
question rather than a preference.
3. Report receipt data honestly. Apple's Mail Privacy Protection pre-loads remote
content, so label every event as a possible open rather than a confirmed one,
and never show a location derived from the request IP.
4. Ask me where scheduled sends execute before writing them. If on-device, make
the UI say plainly that a sleeping machine misses the slot. If server-side,
stop and make me acknowledge that I am now running a credential store.
5. A send is irreversible. Show the resolved local time and the recipient list in
a confirmation for anything scheduled more than an hour out, and keep an
outbox I can cancel from until the moment it leaves.
6. Share-by-link, if you build it at all: authenticated by default, a real
server-enforced expiry with a short default, an access log, attachments
excluded, and a revoke button. Never a bare UUID.
7. Build auto-archive and auto-label before auto-forward, and make forwarding
rules require an explicit confirmation each time a new pattern first matches.
8. Encrypt the local message cache, and make delete remove the body rather than
the index row.
9. Target one mail provider properly before adding a second. Do not abstract
Gmail labels and IMAP folders behind one model — that is where messages go
missing.
10. Out of scope: your own mail server, spam filtering and thread
collaboration. Say so, and note that Newton is $49.99 a year.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Almost always, and the price makes the argument for you: $49.99 a year is under a dollar a week for four platforms and a sync engine somebody else debugs. The honest caveat is the one this product has earned — it has been announced dead three times since 2018 and came back each time under new owners, so treat the export path as part of the purchase rather than an afterthought. If you want a mail client with a longer institutional memory, Thunderbird is free and has outlived most of this category.
$4.17/mo is cheaper than your weekend.
Mail already has a portable format, which makes this one of the easier exits on the site if you plan for it: keep the local store as maildir or export to mbox on a schedule, and never let your database be the only place a message exists. The part with no format is the metadata you invented — snooze times, scheduled sends, receipt events, share links — so dump those as JSON alongside, and expire every share link before you turn anything off. Credentials get revoked at the provider rather than deleted from your disk.
Open-source cross-platform mail client descended from Nylas Mail, with read receipts and send later already implemented.
The former K-9 Mail, and a readable example of how much code a well-behaved IMAP client on one platform actually is.
Questions
Is Newton Mail actually still alive?
Yes, as of August 2026. It sells at $49.99 a year with clients for Mac, Windows, iOS and Android, and the site claims forty thousand subscribers. It is worth knowing the history anyway: it began as CloudMagic, was renamed in 2016, was announced as shutting down in 2018, again in 2020 when Essential wound down, and again in 2024, and it has been revived each time under different owners. The current builds ship from a team that rebuilt it on a lighter desktop-first architecture in 2026.
Why is a personal mail client YOUR FUNERAL rather than DEMO ONLY?
Because two of its headline features act on people who never installed anything. A read receipt measures the recipient; a share link publishes their words. If you strip both out and build a client that reads and composes locally, the verdict genuinely drops — that version's worst case is your own inbox looking wrong for a week. It is the tracking and the publishing that move this into somebody else's problem.
Do read receipts even work any more?
Partially, and that is worse than not at all. Apple's Mail Privacy Protection, on by default since 2021, fetches remote content through a proxy whether or not the message is opened, which means a large share of events register as opens that never happened and hide the recipient's IP. Other clients block remote images outright, producing silence from people who did read. So the signal is noisy in both directions, and the natural human response — following up because the dashboard says they read it and ignored you — is built on a number that cannot support it.
What is the honest minimum for send later?
An outbox on your own machine plus a scheduler that runs when the app is open, with the interface saying so. That covers 'not now, in an hour' and needs no infrastructure. The moment you want 'six in the morning while I sleep', you have decided to run a service that holds mailbox credentials continuously, and that is a different project with a different threat model. Newton charges $49.99 a year in large part for being that service.
- EDPB Guidelines 2/2023 on the technical scope of Art. 5(3) of the ePrivacy Directive
- GDPR Art. 6 — lawfulness of processing
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Your inbox is the reset link for everything else you own. It deserves better than your first sync engine.
Send later means a server that holds your mail password and presses send while you are asleep. Twice, sometimes.
Read receipts mean every link you send routes through a box you own. Turn it off and your sent mail rots.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice