shouldivibecodeit

Should I vibe codeSpike?

Email, chat, notes, and meetings presented in a conversational inbox

Conversational email is a guess about which paragraph is new. Guess wrong and you never see the reply.

?

Their verdict, the Pro (Email App) price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.

Can you build it?asked by canivibecodeit.com ↗KINDAweekend project · weekend to multi-day
?

Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.

Should you ship it?asked by usDEMO ONLYvibe the v0, throw it away.

The honest answer

why the verdict is what it is

Six mail clients on this site already argue about sync engines, credential stores and daemons that press send while you sleep, and every word of that still sits underneath Spike. Take it as read. What earns a separate page is an asymmetry Spike states outright: it turns email into a chat-like experience while external recipients receive a regular email. That one sentence contains the entire build. Your side is bubbles grouped by person; their side is SMTP, unchanged. Two problems fall out of it that no other mail client here has. The first is the parser — to render a message as a bubble you must decide which bytes are new and which are quoted history, signature or legal boilerplate, and no standard tells you. The canonical open-source attempt, Mailgun's talon, has not seen a commit since 2022. Guess wrong and nothing errors: the paragraph a colleague typed underneath the quote simply does not appear, and you learn about it when they ask why you ignored the question. The second is that a chat interface makes promises the transport cannot keep. Edit, unsend, delete-for-everyone, delivered, typing — each of those is a local fiction the moment the other person is not also using your app. Neither problem will get anybody's data stolen. Both are why this stays a project.

What actually breaks

not "if". the specific failures.

  • The quote parser, silently. Nothing throws and nothing logs; the reply somebody typed underneath the quoted block is just not on screen, and the bug surfaces socially rather than technically
  • Signature stripping, which eventually removes the paragraph that merely looked like a signature — a phone number, a delivery date, the one conditional sentence that mattered
  • Every chat affordance you render. Edit, unsend, delete-for-everyone and read receipts do not exist in SMTP, so the UI either lies about them or has to apologise for them in every second conversation
  • Grouping by person instead of by thread, which merges two unrelated conversations with the same colleague and splits one that arrived from their phone under a different From address
  • Rich content squeezed into a bubble. A quoted table, a signature image, a 40MB attachment and a marketing email's HTML all have to survive being reformatted into a chat cell, and they do not
  • The credential store, because a conversational client is only interesting across all your mail — and anything that is not Gmail means recoverable IMAP passwords rather than scoped tokens
  • Threading fidelity, since References and In-Reply-To are advisory in practice and mobile clients rewrite subjects, so your person-grouped view drifts from what everyone else can see

Is that you?

the verdict is a default, not a law

ship it if
  • It is your own mailbox and the client never writes to the server
  • gmail.readonly is enough, and the conversational view is a way of reading rather than a way of filing
  • You would lose nothing but an evening if the local cache were deleted tomorrow
  • You accept that the bubbles are a projection and the raw thread is still the truth
don’t ship it if
  • There is no way to see the original message, so a parser mistake is invisible by construction
  • It runs your work mail and a decision can go missing in it without anyone noticing
  • You are storing IMAP passwords for accounts that are not yours
  • You intend to ship edit or unsend against recipients who are not using your app
  • It archives, deletes or files things automatically based on what the parser decided a message was

If you build it anyway

the checklist, then the prompt that enforces it

  1. Bind a key to "show original": the raw message with headers, quoted history and signature intact. That single feature converts this project's defining failure from silent to visible, and it costs an afternoon.
  2. Treat the conversational view as a projection and never as storage. Do not write a stripped body back over the message, and never let the parser's output be the only copy.
  3. Start read-only. Every interesting problem in a conversational client — grouping, rendering, search, triage — exists before the first server write.
  4. Keep Message-Id, In-Reply-To and References as the underlying model. Person-grouping is a display layer on top and must be reversible to the real thread with one action.
  5. Do not implement unsend or edit for external recipients. A delayed send with a cancel window is the honest version, and the UI should say which one it is doing.
  6. Credentials in the OS keychain, never a config file next to the cache that contains the mail they unlock.
  7. Sanitise message HTML aggressively and block remote images by default. You are rendering documents written by strangers inside the process that holds your mail.
  8. Log every parse decision in a debug mode you can turn on, so "I never saw that" has an answer other than a shrug.
the guardrail prompt
I am building a conversational email client — chat-style bubbles over a normal
mailbox. The failure that matters here is silent omission, not data loss. Apply
these in order and push back when I ask for the fun part first.

1. Start with gmail.readonly, or IMAP with no write operations. No archive, no
   delete, no label changes until everything below exists.
2. Store the full raw RFC 5322 message. The conversational view is derived and
   disposable, and the original is never modified or overwritten by it.
3. Build "show original" before you build the bubble: one keystroke, raw
   source, headers included. It is the only defence against a parser that
   quietly hides a paragraph.
4. Quote and signature detection is a heuristic and the UI must say so — a
   visible, clickable indicator with a byte count wherever content was
   collapsed. Never remove content without leaving a marker.
5. Write the test corpus first: top-posted replies, bottom-posted replies,
   text interleaved inside the quote, Outlook's original-message separator,
   mobile signatures, a forwarded chain three deep. Assert nothing new is
   ever hidden.
6. Model threading on Message-Id, In-Reply-To and References. Grouping by
   person is a view over that, reversible to the real thread in one action.
7. Do not implement unsend, edit or delete-for-everyone. If I ask, explain
   that SMTP has no such operation, then offer a delayed send with a cancel
   window and label it honestly.
8. No read receipts or typing indicators for anyone outside the app, and no
   tracking pixels in my outgoing mail.
9. Credentials go in the OS keychain — never a plist, a dotfile, or a column
   beside the cached messages they unlock.
10. Sanitise incoming HTML and block remote images by default. Assume every
    message body was written by someone who wants something.
11. Out of scope, and say so instead of half-building: a chat protocol between
    users of my app, group video, notes and tasks. Spike is $8 a seat.
paste this before you build — not after something breaks31 lines · 1994 chars

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

just pay for it

The moment this becomes the thing you actually read your mail in rather than something you are building. $8 a seat a month, or $6 on an annual plan, buys a parser that has been corrected against millions of real messages, a sync engine somebody else owns, and mobile clients — and mobile is where a conversational inbox is genuinely better than a thread list, which is also the platform you are least likely to build for yourself.

$8/mo is cheaper than your weekend.

your exit plan, if you already built it

Structurally easy, because the mail is not yours to migrate — it lives on the server and your client is a window. The trap is state that exists nowhere else: a read/unread flag you tracked locally, a pin, a note attached to a conversation, a group you invented that has no counterpart in IMAP. Mirror anything you care about into real labels or folders, or accept that it dies with the app. Then take a Takeout or an mbox export once a year regardless of what you are running, because that is the copy that survives you losing interest.

prior art · someone already did this
Mailspring

Actively maintained open-source desktop mail client with its own sync engine, and the closest reference implementation of the boring half.

Delta Chat Desktop

A messenger whose transport is ordinary email, which is the purest existing take on the idea Spike is selling.

Talonunmaintained

Mailgun's quotation and signature extraction library — the canonical solution to this entry's hardest problem, with no commits since 2022.

Questions

There are already several mail client entries. What is actually new here?

The rendering layer, which the others do not have. Mimestream's problem is sync, Spark's is a server that acts while you sleep, Mailbird's is embedding other people's web content. Spike's is that it reformats other people's messages before you read them, using a heuristic with no specification, and the failure mode is content you never knew existed. That is a correctness bug in a reading tool, which is a different and quieter category of bad.

Why is this demo-only when six other mail clients are your-funeral?

Because of what it does rather than what it reads. The harsher ratings in this category all attach to something irreversible or credentialed running unattended: a send-later daemon, an agent with a write scope, a macro engine bound to a swipe. A conversational client that reads your own mailbox and never writes to the server has one victim, you, and one recoverable outcome, a missed paragraph. Bolt on send-later or an auto-filing rule and it moves up a band immediately.

How hard is quote and signature detection really?

Hard enough that the best-known open-source implementation is a machine-learning library from an email infrastructure company, and hard enough that it has been sitting untouched since 2022 because the long tail never ends. There is no standard for where a reply begins. Outlook, Gmail, mobile clients, mailing lists and a decade of corporate disclaimers each do it differently, and people write inside the quoted block often enough that stripping quotes correctly still loses text.

did you build it?

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.

also on the regret index
MimestreamDEMO ONLY

Your inbox is the reset link for everything else you own. It deserves better than your first sync engine.

MailbirdYOUR FUNERAL

A mail client is a browser you wrote for content sent by strangers, running beside your IMAP passwords.

Spark PremiumYOUR FUNERAL

Send later means a server that holds your mail password and presses send while you are asleep. Twice, sometimes.

last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice