Should I vibe code
Turn one support mailbox into an assigned team inbox with a knowledge base
Every ticket says answered. The replies are in their spam folder, and nothing you built can tell the difference.
?
Their verdict, the Per-ticket 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
A shared inbox is three days of work and the demo is convincing: mail arrives, an agent claims it, a reply goes out. The failure is not dramatic — it is that your version has no idea whether the reply arrived. Sending from your own domain means SPF, DKIM, DMARC and a sending reputation you have never had to think about, and when one provider quietly starts filing your replies as spam, your queue still shows every ticket answered. Dashboards green, customers ignored. That gap between 'sent' and 'delivered' is most of what a help desk is actually selling, and it is the part that takes longer to build than the inbox.
What actually breaks
not "if". the specific failures.
- Deliverability: a reply leaves your relay with a 250, lands in a spam folder, and the ticket says answered
- Collision, when two agents write the same reply because 'who has got this' was filed as a nice-to-have
- The poller, which stops at 2am on a Sunday and looks exactly like a quiet weekend
- Threading on subject lines, so a customer's fourth reply opens their fourth ticket
- Auto-responders answering auto-responders until one out-of-office has been mailed two thousand times
- The knowledge base, which is a public website with a search box and SEO expectations that you now own
- Two sources of truth — assignment in your database, the mail itself in the mailbox — disagreeing the first time somebody archives by hand
Sunday, and a customer posts publicly that your support has ignored her for two weeks. It has not: three replies sit in the outbox table, all marked sent, each with a 250 from the relay. What the table does not record is that her provider started binning mail from your domain nine days ago, when volume from a new IP with no DMARC record crossed a threshold nobody at either company can see. You find it by exporting a month of replies and grouping by recipient domain: one provider, forty conversations, not a single reply since the ninth. Every one of those people thinks you ignored them, and the fix — warming the IP, publishing the records, waiting — takes a fortnight you do not have.
Is that you?
the verdict is a default, not a law
- Outbound goes through a transactional provider with SPF, DKIM and DMARC published, and you consume its bounce and complaint webhooks
- The team is small enough that assignment can be a convention rather than a feature
- Every inbound message is persisted raw before anything acknowledges it
- There is no public knowledge base in the first version
- You are sending customer replies from an SMTP server you administer
- Nothing alerts you when inbound mail stops arriving
- You cannot produce, or delete, every message tied to one email address on request
- Support handles account recovery, refunds or anything a regulator has written an opinion about
If you build it anyway
the checklist, then the prompt that enforces it
- Send through a transactional provider — SES, Postmark, Mailgun — and let it own reputation. Publish SPF, DKIM and DMARC before the first reply goes out, not after the first complaint.
- Consume delivery, bounce and complaint webhooks and surface delivery state on the ticket itself. 'Sent' is not a status; 'delivered' is, and 'suppressed' is the one that saves you.
- Persist inbound mail raw, as full RFC 5322 with headers, before acknowledging the webhook or deleting from the mailbox. A 200 is a promise nobody will repeat.
- Thread on Message-ID, In-Reply-To and References, never on the subject line. When threading is ambiguous, open a new ticket and flag it rather than guessing into an existing one.
- Never auto-reply to a message carrying Auto-Submitted or Precedence: bulk, and rate-limit auto-replies per address per day regardless. Mail loops are cheap to start and expensive to stop.
- Alert on silence. No inbound for an hour is this system's real failure mode and it is indistinguishable from a quiet Tuesday until somebody complains.
- Pick one owner for assignment state — your database or the mailbox — and make the other a mirror. Two sources of truth in a shared inbox produces double replies with mathematical reliability.
- Strip anything shaped like a card number on ingest, before it reaches storage, logs or the search index. Customers paste them; that is simply a fact about support mail.
I am building a shared support inbox: email in, assignment, replies out, and
later a knowledge base. Treat outbound delivery as the product. Apply these and
push back if I ask you to break them.
1. Before any inbox UI, set up sending: a transactional provider, SPF, DKIM and
DMARC records, and a documented from-address. Refuse to send customer mail
from a self-managed SMTP server and explain why in one paragraph.
2. Consume the provider's delivery, bounce, complaint and suppression webhooks
and store the result against each message. The ticket UI shows delivery state,
not send state. A reply with no delivery confirmation after an interval I set
raises an alert.
3. Persist every inbound message raw — full RFC 5322, headers included — before
acknowledging the webhook or removing it from the mailbox.
4. Thread on Message-ID, In-Reply-To and References. Never on subject. Ambiguity
creates a new flagged ticket rather than a guess.
5. Never auto-reply to mail carrying Auto-Submitted: auto-generated or
Precedence: bulk, and rate-limit auto-replies per address per day.
6. Add a heartbeat that alerts when no mail has arrived for an hour, and tell me
where it pages. Silence is how this system fails.
7. Make one system the owner of assignment state and mirror it into the other.
Tell me which you chose and what happens when they disagree.
8. Redact card-number-shaped strings on ingest, before the database, the logs and
any search index.
9. Give me one command that exports and one that deletes everything tied to an
email address — tickets, messages, attachments, audit rows — before you build
the knowledge base.
10. Out of scope for v1: live chat, SLA automation, a public help centre and
customer logins. The last one in particular turns an internal tool into a
public one and changes every authorisation decision in the project.
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
Awkwardly, the $20-a-seat Groove you were comparing your weekend against is not what the pricing page sells any more: Groove became Helply in mid-2026 and the advertised price is now $1 per ticket with a 250-ticket monthly minimum and a $3,000 annual floor, with Groove Classic continuing for existing customers. So for a team of three the honest comparison is Help Scout, or self-hosting FreeScout — both of which already solved deliverability, threading and mail loops, which is precisely the list you were going to get wrong.
Keep the mail as mail: raw RFC 5322 with Message-IDs intact, in a maildir or an object store with a manifest, attachments as files beside it. Tickets are a view over the mail, and every real help desk can import mail. Parsed bodies in a messages table with the headers discarded is the version that cannot be migrated to anything, including your own next attempt.
Mature open-source shared inbox and customer engagement platform, with the mail plumbing already done.
Self-hosted PHP help desk modelled on Help Scout — closest in shape to a small shared support mailbox.
Questions
You already cover Freshdesk, Help Scout, Crisp and LiveChat. What is different here?
Those entries turn on portals, widgets and authorisation — the risk is one customer reading another's ticket. Groove Classic's shape is a shared mailbox: no customer login, no chat widget, so the interesting question moves from 'who can read this' to 'did the reply arrive at all'. That failure is quieter, lasts longer, and does not show up in any dashboard you would think to build.
Is Gmail with labels really not enough?
For three people, it usually is, and that is the most useful advice in this entry. What a shared mailbox lacks is collision detection and a record of who owns what, and both can be a convention until roughly the fifth agent. The moment you start writing code to fix that, you have taken on outbound delivery as your problem.
How likely is the deliverability failure, honestly?
Likely enough that every hosted help desk maintains dedicated infrastructure and reputation teams for it. A new domain sending a few hundred replies a day, from a fresh IP, without alignment between the from-address and the signing domain, is exactly the profile filters are tuned against. The dangerous part is not the filtering; it is that filtering is invisible to the sender unless you deliberately wire up the feedback.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 32 — security of processing (EU)
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.
A dropped support email is invisible. You find out from the refund request.
An AI that answers your customers wrongly is a support ticket that scales.
A chat widget is an unauthenticated write endpoint pointed at your phone. Guess who finds it first.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice