Should I vibe code
Manage a shared email inbox and compact help center for a small team
A dropped support email is invisible. You find out from the refund request.
?
Their verdict, the Standard price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
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
A shared inbox is IMAP plus a UI until you need threading, assignment, SLA timers and the certainty that nothing was silently lost. That certainty is what you are actually paying for.
What actually breaks
not "if". the specific failures.
- Threading, because References and In-Reply-To are advisory and some clients rewrite them, so a reply arrives as a brand new ticket
- Two people answering the same message at once, with no assignment lock, so the customer gets contradictory answers
- A message that fails to parse — odd encoding, a huge attachment — landing nowhere and alerting nobody
- Your outbound replies going to spam, so the customer's silence looks like resolution
- IMAP state, where a crash mid-fetch either loses a message or reprocesses a thousand
A customer emails on Friday about a failed payment. Their client sends the reply with a rewritten Message-ID, so your threading logic files it as a new conversation, at the bottom of a list sorted by most recent activity — which it now has none of, because it is new and nobody has touched it. On Monday you are reading a chargeback notice. The email is right there in the database. It was never unread. It was just never on anyone's screen.
Is that you?
the verdict is a default, not a law
- It is a read-only viewer over a mailbox you already monitor another way
- The team is one person and that person also reads the raw inbox
- Nothing about response time is promised to anyone
- It is the only place support email is seen
- More than one person answers from it
- There is no alert when a message fails to parse or import
- You have promised anyone a response time
If you build it anyway
the checklist, then the prompt that enforces it
- Never delete or move a message out of the source mailbox. Your tool is a view; the mailbox stays the system of record so a bug cannot lose mail.
- Thread on References and In-Reply-To, but fall back to matching by sender plus subject, and always show a possible-related-conversation hint rather than silently splitting.
- Anything that fails to import goes to a visible quarantine with an alert. A parse failure must never be a silent drop.
- Lock a conversation to one assignee while they are drafting, and show other agents that someone is replying.
- Track and alert on oldest-unanswered age. That single number catches most of what goes wrong here.
- Monitor your own outbound deliverability, because a reply in spam looks exactly like a customer who stopped caring.
Before you write a shared support inbox, apply these and push back if I ask you to break them.
1. Treat the upstream mailbox as the system of record. Never delete, move or
mark messages there. Your database is a projection, and it must be safe to
rebuild it from scratch. Tell me this is what stops a bug from losing a
customer's email permanently.
2. Thread on References and In-Reply-To first, then fall back to sender plus
normalised subject. When confidence is low, create the conversation but
surface a 'possibly related' link rather than silently splitting or silently
merging.
3. Any message that cannot be parsed — encoding, MIME structure, attachment
size — goes into a visible quarantine queue and raises an alert. Never
swallow it. This is the failure that is invisible by construction.
4. Make ingestion idempotent by Message-ID so a crash mid-fetch cannot
duplicate or drop.
5. Add assignment with a soft lock: while someone is drafting a reply, show
other agents that they are. Two simultaneous answers is the most common
multi-agent failure.
6. Expose one metric prominently: age of the oldest unanswered conversation.
Alert on it. Most support disasters are a message nobody saw, not a message
handled badly.
7. Send replies through a provider that reports bounces and complaints, and
record delivery status per reply. A reply in spam is indistinguishable from a
customer who went quiet.
8. Log every state change with actor and timestamp, append-only.
9. Out of scope unless I ask, and say so: SLA timers, knowledge base,
satisfaction surveys, chat.
10. In the README, write that a dropped support email is invisible and that the
quarantine queue and the oldest-unanswered alert are the only two things
standing between me and finding out from a refund request.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
The moment a second person answers, or the moment you tell a customer how fast you reply. $25 a month per seat buys threading that has met every broken mail client, and a quarantine for the messages that would otherwise vanish quietly.
$25/mo is cheaper than your weekend.
Because the mailbox stays the source of truth, the exit is mostly free: point a real help desk at the same mailbox and it can rebuild history from the messages themselves. Keep your own metadata — assignment, notes, tags — exportable as CSV, since that is the only part that does not live in the mail.
Mature open-source customer engagement and shared-inbox platform.
Questions
Why not just delete messages from the mailbox once imported?
Because it removes your only safety net. While the mail is still upstream, any bug in your importer is recoverable by re-syncing, and any competing tool can be pointed at the same mailbox. Once you have moved it, your database is the sole copy and every parsing bug becomes permanent loss.
Is email threading really that unreliable?
The headers are advisory and widely mangled — some clients rewrite Message-ID, some strip References, mailing lists rewrite both. Any threading implementation is heuristic. The important part is not being perfect, it is failing visibly: show a possible match rather than quietly filing a reply as a new ticket.
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.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice