Should I vibe code
Send later, reminders, scheduling, and inbox pause for Gmail
Read receipts mean every link you send routes through a box you own. Turn it off and your sent mail rots.
?
Their verdict, the Personal 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
Strip out send-later, which is a scheduled job with a mail credential and an argument made elsewhere on this site, and what is left is stranger. Read receipts and click tracking mean your build inserts a pixel into mail you send to other people and rewrites their links through a host you own — you are now running a small surveillance service against your own correspondents, and a redirector that every link in your sent archive depends on forever. Inbox Pause is stranger still: the only way to hide arriving mail is to mutate the rules of the mailbox itself, so a resume step that fails leaves your inbox quietly diverted with nothing anywhere reporting an error.
What actually breaks
not "if". the specific failures.
- Inbox Pause, because pausing an inbox means writing a Gmail filter that diverts everything — and if the resume step fails, mail keeps skipping the inbox silently with no error raised anywhere
- The OAuth refresh token, which Google expires after seven days while the app's publishing status is still Testing, so the daemon you built stops every week and you will blame the cron
- Click tracking, which rewrites every link in your outgoing mail through a redirector you own — stop paying for that host and every link in every message you have ever sent dies, in other people's archives, permanently
- Read receipts, which are a pixel logging a correspondent's IP address and open time on your server, with no notice, no consent and no way for them to object
- The numbers themselves, since Gmail proxies remote images and Apple Mail Privacy Protection prefetches them, so 'opened' frequently means a datacentre looked at it
- Scheduled sends at the boundaries: a worker restarted mid-run sends twice, a queue drained during a deploy sends nothing, and both failures are discovered by the recipient
- Response tracking, which has to read whole threads — a Gmail restricted scope, and restricted scopes come with an annual third-party security assessment if the app is ever published beyond you
The week has been unusually quiet, which you took as a good sign until Thursday. Inbox Pause did exactly what it was built to do on Monday: a filter matching everything, applying a label instead of the inbox, added by your script and due to be removed on resume. The resume job ran on schedule, got a 403 from a refresh token Google had expired at seven days because the OAuth consent screen is still in Testing, logged it at info level, marked itself complete and cleared its own state. Four days of mail is sitting under a label nobody looks at. In it are two invoices, a reply from a client who has since given up and messaged you on LinkedIn, and a calendar invite for a meeting that happened yesterday without you.
Is that you?
the verdict is a default, not a law
- It is send-later only, for your own account, from a machine you already trust with the mailbox
- It uses Gmail's own scheduled send rather than holding the message yourself
- Nothing is inserted into or rewritten in the mail that reaches the recipient
- You would notice within an hour if it stopped running
- It embeds a tracking pixel or rewrites links in mail going to other people
- It modifies filters, labels or forwarding rules on the mailbox as a mechanism — that is a change you have to remember to undo
- It holds mail credentials or an OAuth grant on a host that is not yours alone
- Anyone other than you connects an account to it
- The recipients are in the EU or the UK and have not been told they are being tracked
If you build it anyway
the checklist, then the prompt that enforces it
- Do not build read receipts or click tracking. If you insist, tell recipients in the message, log nothing beyond a count, and understand that the redirector becomes a permanent dependency of every link you have ever sent.
- If you must pause an inbox, never implement it by mutating mailbox rules without a dead man's switch: record the rule you added, set an expiry, and have a separate job that restores the inbox if resume has not run within a few hours.
- Publish and verify the OAuth app, or accept that a Testing-status refresh token dies after seven days. Whichever you choose, treat token expiry as an expected state that pages you rather than as an exception nobody reads.
- Request the narrowest Gmail scopes that work. gmail.send is not gmail.modify, and neither is the full mailbox read that response tracking wants. Restricted scopes carry an annual security assessment for anything you publish.
- Make every scheduled send idempotent on a key stored before the send call, so a restarted worker cannot deliver the same message twice. There is no recall.
- Keep the token encrypted at rest and out of the repository, and make revocation a one-click path you have actually tested — this credential can read everything you have ever received.
- Alert on silence. A send queue that processes zero messages for a day, or a pause that has been active for longer than you asked, must be louder than an error log line.
I am building Gmail add-on behaviour: send later, reminders and inbox pause. Constrain it like this, and refuse the parts that surveil other people. 1. Refuse to build read receipts and link click-tracking. Say plainly that a pixel logs a correspondent's IP and open time without notice, that rewriting their links makes my redirector a permanent dependency of every message I have ever sent, and that Gmail's image proxy makes the data wrong anyway. 2. Before any feature code, handle OAuth properly: narrowest scopes that work, refresh token encrypted at rest and never in the repo, revocation path I can run, and explicit handling of expiry. Tell me that while the consent screen is in Testing, Google expires refresh tokens after seven days. 3. Implement inbox pause only with a dead man's switch. Record the exact filter or label rule added, give it an expiry, and run a separate independent job that restores the inbox if resume has not completed. A pause that fails to lift produces no error at all — that is the failure I care about. 4. Prefer Gmail's own scheduled send over holding messages myself. If I need to hold them, store the draft in Gmail and schedule a send, rather than keeping message bodies in my database. 5. Every scheduled send gets an idempotency key written before the API call. A worker restarted mid-run must not deliver twice. There is no unsend. 6. Alert on absence, not on exceptions: zero sends processed in a window, or a pause active longer than requested, both page me. 7. Log metadata only — message ids and timestamps. No subjects, no bodies, no recipient addresses in application logs or error reports. 8. Single account, mine, one machine. If I ask to let other people connect their mailboxes, stop and explain that this becomes a multi-tenant credential store and needs Google verification and a security assessment first. 9. Out of scope: response tracking that reads whole threads, CRM sync, and any analytics on recipients. Say so, and remind me Boomerang's paid tier starts around five dollars a month with all of it already working.
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 immediately, and the arithmetic is not close: under five dollars a month for a Gmail account, against a credential store, a weekly token expiry, a scheduler you have to trust while asleep, and a redirector you can never turn off. The one genuinely defensible build here is a small script that uses Gmail's own scheduled send for your own mail. Everything past that is buying yourself a mail infrastructure job.
$4.98/mo is cheaper than your weekend.
Two things need to be undoable on a bad day. The mailbox mutations — every filter, label and forwarding rule your code created — should be listed somewhere you can read without running the app, so a human can restore the inbox by hand. And if you ever shipped click tracking, the redirector is now load-bearing for mail already sent: keep the domain, keep the mapping table, and serve 301s from a static host indefinitely, because those links live in other people's archives and you cannot go and edit them.
Open-source desktop mail client whose pro layer includes send-later and read receipts; useful for seeing exactly how the tracking is wired.
Open-source Gmail assistant with a real, readable implementation of Google OAuth, scopes and token handling.
Questions
Why is inbox pause treated as more dangerous than send later?
Because send later fails loudly — the message does not arrive and somebody says so. Pause fails silently in the direction of nothing happening. The mechanism is a rule on your mailbox that diverts mail away from the inbox, so the failure mode is an ordinary quiet week, and quiet weeks do not generate alerts. By the time you investigate, the thing you missed has already had its consequence.
Everyone uses tracking pixels. Why single this out?
Because building it yourself removes every layer that normally sits between you and the consequence. A commercial sender has a privacy notice, a data processing agreement, a retention policy and a legal team who decided this was defensible. Your version has an IP address and a timestamp in a table, attached to a named person who was never told, and if they are in the EU or the UK you need a lawful basis for that and you do not have one written down.
What is this seven-day token thing?
Google issues refresh tokens that expire after seven days to OAuth clients whose consent screen is set to external and whose publishing status is still Testing — which is where every personal project sits, because moving out of Testing means verification. So the daemon works beautifully for a week and then stops, and because it stops on an auth error inside a background job, the symptom you actually see is that a scheduled message did not send.
Can I at least keep the send-later part?
Yes, and it is the one piece worth keeping. Use Gmail's own scheduled send through the API rather than holding the message yourself: the mail body stays in Google's hands, the delivery is theirs to get right, and your code is reduced to setting a time. That version is close to a ship-it and it is not what this verdict is about.
- GDPR Art. 6 — lawfulness of processing (the basis you need for open and click tracking)
- Google API Services User Data Policy (restricted scopes and assessment requirements)
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.
Send later means a server that holds your mail password and presses send while you are asleep. Twice, sometimes.
You are not building a mail client. You are building a lodger inside three of them, evicted on their release schedule.
An autonomous agent with delete permission on your inbox is a very fast way to lose something.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice