Should I vibe code
Connect interview notes and support feedback to product issues and decisions
A support inbox that quietly loses one email in a hundred is indistinguishable from a company that ignores you.
?
Their verdict, the Starter 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
The half of Productlane that looks like the product - a feedback board, upvotes, a public roadmap, a changelog - is a weekend and it is not the half that matters. The other half is a shared inbox that receives real email from real customers, threads it, replies to it, and lets an AI agent answer some of it unsupervised. Email is a protocol with thirty years of edge cases and exactly one visible failure mode: silence. Get the threading wrong and one customer reads another's ticket; get deliverability wrong and you look like a company that ignores people; get the agent wrong and your product made a promise nobody at your company approved.
What actually breaks
not "if". the specific failures.
- Inbound threading - References, In-Reply-To, subject munging - where being wrong once shows one customer another customer's conversation
- Outbound deliverability, which fails silently and looks exactly like not replying
- Auto-responders and out-of-office replies bouncing off your own auto-reply, the classic two-robots-talking incident
- The AI agent answering confidently about a refund policy it inferred from a help article nobody updated since March
- A public feedback board that publishes the company name of whoever filed the request, next to what they said about their own roadmap
- Two-way Linear sync, which is fine until a rename on one side orphans the link on the other and duplicates start breeding
- Attachments, which are whatever a customer felt like emailing you, stored on your bucket, served from your domain
- Deletion requests, which have to reach the inbox, the board, the changelog, the search index and the embeddings
A customer replies to a ticket and your threading falls back on subject line matching, because their mail client stripped the References header and you wrote that fallback in week one. The reply lands on an open conversation with the same subject - 'Re: Billing question' - belonging to a different company. Your agent, seeing a thread, sends the running context in the next response. Now one of your customers has a transcript of another customer's billing dispute, complete with their account email, and the first thing they do is screenshot it. There is no patch for an email that has already been delivered, and the disclosure conversation starts with you explaining what your subject-matching fallback was for.
Is that you?
the verdict is a default, not a law
- It is a read-only view over an inbox you still keep in a real mail provider
- The feedback board is internal, or public with no customer names attached
- Any AI drafts a reply into the agent's editor and a human sends it
- Nobody outside the company depends on getting an answer through it
- It is the address customers actually write to when something is broken
- An AI agent can send a reply on the company's behalf with nobody reading it first
- You cannot answer a deletion request across every place a message got copied
- The board publishes who asked for what, and your customers are each other's competitors
If you build it anyway
the checklist, then the prompt that enforces it
- Do not become the mail server. Keep a real provider as the system of record, treat your app as a client over IMAP or their API, and you get an undo when your threading is wrong.
- Thread on Message-ID, References and In-Reply-To only. Never fall back to subject matching - that fallback is the cross-customer leak, and it will look like it works for months.
- The AI agent drafts; a human sends. If you ever change that, restrict it to an explicit allowlist of question types and put a visible 'answered automatically' label on every reply.
- Suppress replies to no-reply, mailer-daemon and anything carrying Auto-Submitted or List-Id, and rate-limit per thread. Loops are cheap to prevent and expensive to explain.
- Publish nothing to the public board that identifies a customer unless they explicitly opted in on that submission, and default the display name to blank.
- Build deletion as one command that enumerates every store - messages, attachments, board posts, changelog mentions, search index, embeddings - and fails loudly if a store is missing.
- Make Linear the one-way destination first. Bidirectional sync is a distributed systems problem wearing a checkbox.
I am building a shared support inbox with a public feedback board and an AI
agent. Customers will email it. Apply these and push back if I ask you to
break them.
1. Do not build a mail server. Keep an existing provider as the system of
record and treat my app as a client over their API or IMAP, so a bug in my
threading is recoverable.
2. Thread strictly on Message-ID, In-Reply-To and References. Do not implement
a subject-line fallback under any circumstances - explain to me that it is
the mechanism by which one customer sees another customer's ticket.
3. Before any reply UI, build the suppression list: never respond to
no-reply addresses, mailer-daemon, or messages carrying Auto-Submitted,
Precedence: bulk or List-Id. Rate-limit outbound per thread.
4. The AI agent may only draft. Sending requires a human action. If I later
ask for autonomous replies, restrict them to an explicit allowlist of
question types, label every one as automatically generated, and log the
sources it used.
5. Ground the agent only in documents I marked as current, and make it say it
does not know rather than infer policy. It must never state a refund,
pricing, security or legal position that is not verbatim in a source.
6. Build deletion before display. One command that enumerates every store -
messages, attachments, board entries, changelog mentions, search index,
embeddings - and fails loudly if a new store was added without being
registered.
7. Public board entries are anonymous by default. Displaying a customer name
or company requires an explicit opt-in recorded on that submission.
8. Attachments are stored with random keys, served through an authorising
proxy, and never from a guessable public path. Assume they contain
invoices and screenshots of account pages.
9. Set up SPF, DKIM and DMARC on the sending domain before the first reply
goes out, and monitor bounces and complaints somewhere I will actually
look.
10. Linear sync is one-way to start with. Do not propose bidirectional sync
until the one-way version has been running for a month.
11. Out of scope unless I ask: SLA policies, CSAT surveys, multi-brand
portals, live chat.
12. If I tell you real customers are already emailing this address, say that
Productlane starts at $29 per seat and that the inbox is the part worth
buying.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 customers email it rather than you. $29 per seat buys the inbox mechanics - threading, bounce handling, deliverability, attachment storage - which is exactly the part that fails invisibly and the part an agent will get 95% right. Build the feedback board yourself if you want; it is genuinely a weekend and nothing catches fire when it is down.
$29/mo is cheaper than your weekend.
The exit is whether the mail still exists somewhere that is not your app. If a real provider holds the mailbox and you built a client over it, you quit by closing the tab. If you ingested everything into your own Postgres and deleted from the server, then conversations, attachments and the reply history are a migration project you will do badly under time pressure. Export conversations as RFC 5322 with headers intact, not as rows in a table you designed.
Open-source customer-feedback portal with voting and status workflows.
Open-source shared inbox and live chat, with the email threading and channel plumbing already survived by other people.
Questions
canivibecodeit says KINDA. Why are you two bands harsher on the same product?
Because we are answering different questions about the same build. They are right that the board, the changelog and the Linear wiring come together quickly. Our objection is the inbox: once your customers are writing to it, every silent failure - a bounced reply, a message threaded onto the wrong conversation, an agent answering from a stale help article - lands on somebody who did not choose your code and has no way to route around it.
Is the AI support agent really worse than a human answering slowly?
It is worse in one specific way: it is confident and it scales. A slow human gives a wrong answer once. An agent grounded on documents nobody has curated gives the same wrong answer to everyone who asks that question, in your company's voice, and you find out when someone quotes it back to you in a dispute. Drafting is most of the value with none of that.
What is the smallest version that is actually fine to build?
A read-only reader over the mailbox you already have, plus an internal board. You get the triage view, the tagging and the Linear links, and every reply still leaves through the mail client your customers were already reaching. That version is a weekend, and nothing in it can drop a message on the floor.
- GDPR Art. 5 - principles relating to processing of personal data
- GDPR Art. 32 - security of processing
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 public feedback board is a public spam target with a voting mechanism attached.
An open post box on your own domain is a spam farm with your favicon on it.
Live chat is a promise that someone is there. Your uptime is now a customer expectation.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice