Should I vibe code
Create a cross-platform focused email client with snooze, send later, and local search
Send later means a server that holds your mail password and presses send while you are asleep. Twice, sometimes.
?
Their verdict, the Plus 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
Read the feature list again and notice what every headline item has in common. Snooze, send later, follow-up reminders, cross-device sync, shared drafts: none of them work if the only thing running is an app on a laptop that is currently shut. To get Spark's actual behaviour you have to build a service that stays awake and acts on your mail while you sleep, which means that service holds live credentials for every account you added — and "every account" here includes the IMAP providers that never got an OAuth story, so you are storing recoverable passwords rather than scoped tokens. Then you point that service at the two operations you cannot take back. A send-later that fires twice has sent twice. A snooze that never returns is not an error anyone sees; it is a message that quietly stopped existing on the day you needed it.
What actually breaks
not "if". the specific failures.
- The scheduler, in the only two ways schedulers break: at-least-once delivery sends your carefully timed email twice, at-most-once quietly never sends it, and you get to choose which failure you would rather explain
- Snooze, which is delete-and-recreate under the hood on most providers. The message loses its thread, its flags and its original date, and if the return job dies mid-flight it loses the message
- Credential storage, because Exchange, iCloud and the long tail of IMAP hosts do not all hand you a scoped token. Some of what your daemon needs is a password, at rest, usable from anywhere
- Multi-provider IMAP itself: servers that lie about UIDVALIDITY, that drop IDLE after four minutes, that rate-limit APPEND, that report folder names in modified UTF-7 nobody parses correctly the first time
- Cross-device state. Snoozes and reminders live in your database, not the mailbox, so the phone and the laptop disagree and there is no server-side truth to reconcile against
- Team features, the moment you add them: shared drafts and delegated inboxes mean a colleague's mail is now flowing through code you wrote on a Sunday
- Timezones and DST, which is where "send tomorrow at 8am" turns into 7am for three weeks a year
The queue worker had been restarting cleanly for months, so nobody looked at it. Then a deploy left two containers running the same cron, five seconds apart, and neither had a lock. At 06:00 the twelve scheduled messages went out; at 06:00:05 they went out again. Most were newsletters and nobody cared. One was a fee revision to a client, and the duplicate arrived with a different Message-ID, so their thread shows it as a second, separate email — which is why the reply asks, reasonably enough, whether the price changed twice. You cannot unsend either copy. The fix is four lines of advisory lock; the conversation you now have to have is not four lines.
Is that you?
the verdict is a default, not a law
- Everything happens while the app is open on one machine, and you have accepted that a scheduled send at 6am means being awake at 6am
- Every account authenticates over OAuth and the tokens live in the OS keychain, not in a database your worker reads
- Snooze is implemented as a local flag over an unchanged server-side message, so the worst bug hides a message from your own view instead of moving it
- It is single-account, single-user, and no colleague's mail has ever passed through it
- There is a server holding IMAP passwords or long-lived refresh tokens for accounts you cannot afford to lose
- The send queue has no idempotency key and no lock, which is the default state of every generated job runner
- Snooze physically moves messages between folders and you have not tested what happens when the return job dies halfway
- You added the team features and other people are now trusting your delivery guarantees with their client correspondence
If you build it anyway
the checklist, then the prompt that enforces it
- Build the outbox before the composer. Every scheduled send gets a stable idempotency key, a single-owner lock, and a state machine with an explicit 'sent' transition written before the send, not after.
- Never move a message to implement snooze. Set a local flag and filter the view. The mailbox stays untouched, so the failure mode is a display bug rather than lost mail.
- OAuth wherever the provider offers it, and refuse to add providers that require a stored password until you have decided where that password lives and who can read it.
- If a daemon must hold credentials, it gets its own encrypted store, its own key, and a written answer to what happens when the host is compromised. "It's just my VPS" is the answer that ages worst.
- Put a visible, per-message log in the UI: scheduled at, attempted at, result. The failures that hurt here are the silent ones, so make silence impossible.
- Store scheduled times as UTC plus the originating IANA zone, never as a local wall-clock string, and write the DST test before you need it.
- Test against three providers you did not design for. Gmail's API is not IMAP, and the first Exchange account will teach you that at an inconvenient moment.
I am building a cross-platform email client with snooze, send later and
follow-up reminders across several accounts. The dangerous part is a background
process that holds mail credentials and performs irreversible actions
unattended. Work in this order and argue with me if I skip ahead.
1. Before any feature, write down where credentials live for each provider I
name. Prefer OAuth everywhere it exists. If a provider needs a stored
password, say so and tell me what an attacker with the host gets.
2. On desktop, tokens go in the OS keychain. If a server-side worker needs them,
they go in a separate encrypted store with its own key, never in the same
database as message bodies.
3. Build the outbox first: a durable queue with an idempotency key per scheduled
message, a single-owner advisory lock, and states queued/claimed/sent/failed.
Write a test that runs two workers at once and asserts one delivery.
4. Record the provider's response and the resulting Message-ID before marking
anything sent. On ambiguity, surface it to me rather than retrying blindly.
5. Implement snooze as a local flag with a filtered view. Do not move, copy or
re-append messages on the server. If I ask for real folder moves, first
explain what happens when the return job dies mid-move.
6. Store schedules as UTC plus the IANA timezone the user chose, never a local
wall-clock string, and include a DST-boundary test.
7. Give me a screen showing every scheduled and snoozed item with its attempt
history. Failure must never be silent.
8. Handle IMAP properly: UIDVALIDITY changes mean invalidate and refetch, folder
names are modified UTF-7, IDLE drops and must be re-established, APPEND can
be rate-limited. Gmail behaviour is not universal.
9. Back off with jitter on every transient error and cap retries. A tight retry
loop against a mail host gets the account throttled or locked.
10. Out of scope until I ask: shared inboxes, delegated access and team drafts.
The moment another person's mail is in here the risk stops being mine, and
$10 a month starts looking like the responsible option.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 a scheduled send matters to someone other than you. $10 a month is a delivery pipeline that has already survived duplicate-send bugs, an IMAP compatibility matrix nobody would choose to own, and the DST weekend. The bit you were excited to build — the triage UI, the keyboard shortcuts, the unified inbox — is genuinely fun and genuinely yours. The bit that presses send at 6am is worth outsourcing.
$10/mo is cheaper than your weekend.
Mail is the one category where the exit is nearly free, provided you stayed honest about where truth lives. If the mailbox is the database and your app is a view, quitting means uninstalling, revoking OAuth grants and rotating any password the daemon ever held. What does not survive is everything you invented on top: snoozes, reminders, follow-up flags and shared drafts exist only in your schema. Mirror them into real IMAP keywords or labels as you create them and they will still be there in Thunderbird. Do not skip the credential rotation — the exit plan for a service that held your mail passwords is not deleting the VPS.
Well-maintained IMAP client and server library whose issue tracker is a fair preview of how much of this protocol is edge cases.
Twenty years of open-source webmail across every IMAP server in the wild, still actively maintained.
Questions
Can't I do send-later entirely on the device?
You can, and it is by far the safer design — the app wakes, checks the queue, sends. The catch is that it only works when the app is awake, so "schedule for 8am Monday" means the machine has to be on and unlocked at 8am Monday. That is a perfectly reasonable product; it just is not the product Spark sells, and pretending otherwise is how you end up building a credentialed daemon by accident.
Why is snooze more dangerous than it looks?
Because the obvious implementation moves the message out of the inbox and a job moves it back. Every step of that touches the server: the copy can succeed while the delete fails, the return job can run against a folder whose UIDVALIDITY changed, and a message that came back loses its flags and its position in the thread. A local flag and a filtered view gives you the same user experience with none of it.
Is a stored IMAP password really worse than an OAuth token?
Materially, yes. A token is scoped, revocable from the provider's dashboard and often refresh-bound to your app. A password is the account — mail, contacts, the recovery flow for whatever else uses that address — and it usually still works after you have deleted your project and forgotten the VPS existed.
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.
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.
An agent with inbox access takes instructions from anyone who knows your email address.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice