Should I vibe code
Email tracking, scheduling, notes, contacts, and AI assistance
You are not building a mail client. You are building a lodger inside three of them, evicted on their release schedule.
?
Their verdict, the Smart 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
The mail clients elsewhere on this site ask you to build a client. Mailbutler asks you to build a lodger: code that runs inside Apple Mail, inside the Gmail tab and inside Outlook, with read access to every message in all three and control over none of them. That is a worse deal than it sounds. Apple deprecated the old Mail plugin API and replaced it with MailKit extensions that can do a fraction as much; Chrome moved everything to Manifest V3; Outlook is still migrating off COM add-ins. Your code breaks on somebody else's release schedule, in somebody else's process, which means "Mail keeps crashing" is now your bug report. Underneath that sit three things that outlive the plugin: a pixel logging your correspondents' opens on a server you own, a link rewriter that every URL in your sent archive depends on forever, and a mail-merge button attached to the address your invoices come from.
What actually breaks
not "if". the specific failures.
- The host application, which you do not control — Apple replaced Mail bundles with far weaker MailKit extensions, and every macOS release since has disabled somebody's plugin on upgrade
- The Chrome extension's permissions, because reading Gmail means host access to mail.google.com, which is the most alarming dialog a user will ever accept in exchange for a send-later button
- Scheduled sends, which fail quietly — the message you wrote on Friday for Monday morning is discovered missing by the recipient, not by you
- The tracking pixel, which records a correspondent's IP address and read time on your server with no notice and no way to object, and which Gmail's image proxy and Apple Mail Privacy Protection have already turned into fiction about half the time
- Click tracking, which routes every link you have ever sent through a host you own — stop paying for it and your sent mail rots inside other people's archives
- Mail merge out of your everyday mailbox, which walks into Gmail's daily recipient limit and, past it, into a suspension of the address your invoices come from
- Signature injection, which rewrites the HTML of outgoing mail and will one day mangle a reply chain in a way you only hear about second-hand
- The shared inbox, the moment a colleague's mail starts flowing through your notes, assignments and read receipts
The macOS point release lands on a Tuesday and you install it, because you always install it. Mail relaunches, the extension is listed as incompatible and switched off, and nothing anywhere says so — the extensions pane is two menus deep and you have no reason to open it. Send-later had been running inside the extension rather than on a server, because that was simpler and it worked. For nine days nothing sends. The queue is intact, timestamped and entirely local. You find out when a client forwards you their own follow-up asking whether their brief ever arrived, and the reply you scheduled for the morning after their deadline is still sitting in a SQLite file with a delivery date in the past.
Is that you?
the verdict is a default, not a law
- It targets one client, and that client is Gmail — an extension over the Gmail API is a different and much smaller project than a MailKit extension
- The features are additive and local: notes on threads, snippets, templates, a keyboard shortcut. Nothing that alters an outgoing message
- Scheduling is handed to the provider's own send-later rather than a queue you have to keep alive
- Yours is the only mailbox it touches
- It inserts tracking pixels or rewrites links in mail going to other people
- It is expected to work across Apple Mail, Gmail and Outlook — three unrelated products with three unrelated deprecation schedules
- A colleague's mail flows through it
- Personalised bulk sending comes out of your primary address
If you build it anyway
the checklist, then the prompt that enforces it
- Pick one host application and build only for it. Apple Mail, Gmail and Outlook share no code, no lifecycle and no extension model — the second one is not thirty per cent more work, it is a second project.
- Treat "the extension is disabled" as a first-class error state. Heartbeat it and warn loudly, because a silently dead plugin is indistinguishable from a quiet week.
- Never schedule sends inside the extension. Use the provider's own scheduled send where it exists; where it does not, put the queue somewhere that reports failures to you rather than to the recipient.
- Do not build open tracking. If you build it anyway, say so in the signature, store no IP addresses, and accept that you are collecting behavioural data about people who never agreed to it.
- Never rewrite links through a host you own. That redirector is a permanent obligation embedded in other people's archives, and there is no way to switch it off that is not a mass link-rot event.
- Keep mail merge off your primary address, behind a hard per-run cap, with a dry run that prints the recipient list and one fully rendered message before anything is delivered.
- Store tokens and credentials in the OS keychain, never in extension storage, and request the narrowest scope that works.
I am building an email productivity add-in that runs inside a mail client I do not control. Constrain the design before you write a single feature. 1. Ask which one host I am targeting — Apple Mail, Gmail or Outlook — and refuse to design for more than one. They share no extension model and no deprecation schedule. A second host is a second project, not a flag. 2. Before any feature, build the liveness check: a heartbeat the user can see, and a loud persistent warning when the add-in is disabled or incompatible. A silently dead plugin looks exactly like a quiet week, and that is the failure I care most about. 3. Do not implement scheduled sending inside the extension. Use the provider's own scheduled send if it exists. If it does not, the queue lives in a process that can alert me, and every queued message carries an idempotency key written before delivery. 4. Refuse open tracking by default. If I insist, first tell me I am logging a correspondent's IP address and read time with no notice, that Gmail's image proxy and Apple Mail Privacy Protection make the numbers unreliable anyway, and then store no IP addresses at all. 5. Never rewrite links through a host I own. Say plainly that a redirector is a permanent obligation living inside other people's archives, and that turning it off breaks mail I sent years ago. 6. If I ask for mail merge: a hard cap per run, a dry run that prints the full recipient list and one rendered message, and a refusal to send from the same address my invoices come from. 7. Credentials and tokens go in the OS keychain, never in extension storage. Request the narrowest scope that works and write in the README what each scope actually grants. 8. Out of scope, and say so rather than stubbing it: a second host application, shared-inbox features that route a colleague's mail through my store, and any telemetry that leaves the machine.
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
As soon as more than one client is involved, and fourteen dollars per person per month is mostly not about features. It is about somebody else absorbing the next Apple Mail deprecation, the next Chrome manifest migration and the next Outlook add-in model, on their engineering budget rather than your Saturday. The genuinely defensible homemade version is a single-host, single-user, read-and-annotate extension that never touches an outgoing message. Everything past that and you have bought yourself three permanent porting jobs.
$14/mo is cheaper than your weekend.
The notes, templates and snippets are yours and should be exportable as JSON keyed by message id from day one, because message ids are the only thing that survives moving between clients. The two things with no exit are the redirector and the tracking pixel: every link you rewrote and every image you served lives in mail you cannot edit, in archives you do not own. If you build either, the exit plan is to keep that hostname resolving forever, which is not an exit plan — it is the reason not to build it.
The unofficial Gmail JavaScript API almost every Gmail extension is built on, still maintained.
Open-source desktop mail client — not a plugin, which is the point: owning the client is a different and in some ways safer project.
Questions
Why is a plugin riskier than writing my own mail client?
Because a client fails on your schedule and a plugin fails on theirs. If you own the client, an OS update might break a feature and you fix it when you can. If you are a guest inside Apple Mail, an OS update can disable you outright between one reboot and the next, with no error surfaced to the user and no way to ship a fix through a review queue you do not control. You also inherit the host's crashes: when your extension misbehaves, the user's experience is that Mail is broken.
Is email open tracking actually a problem, or just impolite?
Both, and it is also increasingly useless. Technically it is a one-pixel image on your server that records IP address and timestamp for a person who never agreed to it, which in the EU needs a lawful basis you almost certainly have not thought about. Practically, Gmail proxies remote images and Apple Mail Privacy Protection prefetches them, so a large share of your "opens" are datacentres. You are taking on a data-protection question in exchange for a number you cannot trust.
What is the one feature I should never let an agent build here?
Click tracking. It is twenty lines — rewrite each href to point at your host, log, redirect — and it is the only feature on the list that you can never take back. Every link in every message you have ever sent now depends on a hostname you keep paying for. Stop, and years of your outgoing mail becomes dead links in other people's archives, including mail sent to people you will never be able to notify.
I only want send-later. Is that fine?
If the provider offers scheduled send, yes — call theirs and you are done in an afternoon. The dangerous version is the one where you hold the message and a credential and press send yourself, because now a scheduler running on your laptop is the reason a client did or did not hear from you, and its failure mode is silence.
- GDPR Art. 6 — lawfulness of processing (EU)
- CAN-SPAM Act: A Compliance Guide for Business (FTC)
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.
Read receipts mean every link you send routes through a box you own. Turn it off and your sent mail rots.
An autonomous agent with delete permission on your inbox is a very fast way to lose something.
Your inbox is the reset link for everything else you own. It deserves better than your first sync engine.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice