Should I vibe code
Automated testimonial asks, follow-ups, approval, and embeddable proof
You built a machine that asks every customer, then publishes only the answers you liked. That has a rule number now.
?
Their verdict, the Founding Pro 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
Two entries here already cover the testimonial wall: Testimonial.to for other people's faces on your infrastructure, ShowTrust for the takedown request eighteen months later. Proofling's shape is different enough to change the verdict. It connects to Stripe to pull your customer list, emails all of them on a schedule, chases the ones who do not reply, badges the ones who paid as verified buyers, and publishes the answers you approve. Every one of those verbs has somebody else's rules attached. The Stripe key is a read grant on your entire revenue history sitting in a side project. The follow-up sequence is unsolicited commercial email with a compliance surface. The verified-buyer badge is a factual claim in an advertisement, only as true as the join you wrote between a testimonial and a charge. And the approval queue — the feature that makes the wall look good — is the thing the FTC's 2024 review rule has a section about, once your page implies it shows what customers said rather than what you chose to keep.
What actually breaks
not "if". the specific failures.
- The Stripe connection: a read key over your entire customer and revenue history, held by a side project, so that a cron can email everyone in it
- The verified-buyer badge, which is a factual claim in an advertisement and is exactly as reliable as the email-to-charge join you wrote in twenty minutes
- Follow-up sequences that keep firing after someone replies 'please stop', because the reply lands in an inbox and the sequence lives in a cron
- The public submission endpoint — a form on your domain that stores video and renders arbitrary text back onto your own marketing page
- The embed script, loaded from a box you administer onto a live site; when it 404s, your homepage renders an empty rectangle above the fold
- Deletion eighteen months later, when the person wants their face gone and it is in the wall, the OG image, a CDN cache, three exports and proof.json
- The approval queue quietly becoming a suppression mechanism, which is a named practice with a rule number rather than a design choice
The email arrives from a customer you genuinely liked. She gave you a video testimonial in February, left the company in June, and wants it down. It is not on the wall any more — you unpublished it in four seconds and felt good about that. Then you start looking. It is in the CDN cache with a year-long TTL. It is baked into the OG image on the case-study page. It is in the proof.json export that a prospect downloaded and an AI crawler ingested. It is in last quarter's pitch deck, and in the nightly database dump you have kept every night since March. Unpublishing was a boolean. Deleting is an afternoon of archaeology, and you are doing it while composing a reply that has to sound calm.
Is that you?
the verdict is a default, not a law
- You paste in testimonials you were given, by hand, and the wall is static HTML with no submission endpoint at all
- Nobody is emailed by a schedule — the asks are messages you personally send
- Every quote is published with the sender's written permission, kept somewhere you can find it in two years
- The badge next to a name is something you can prove from a receipt, or there is no badge
- A cron is emailing your customer list without a suppression list, an unsubscribe path and a physical address
- You are labelling testimonials 'verified' on the strength of a fuzzy email match
- Your Stripe key is broader than read-only on customers, or lives anywhere near the machine serving the public submission form
- You have no deletion path that reaches caches, exports and generated images
- You collect testimonials from everyone, publish a curated subset, and describe the result to visitors as what your customers say
If you build it anyway
the checklist, then the prompt that enforces it
- Build deletion before you build collection. One command that removes a testimonial from the database, the wall, every export, every generated image and the CDN, and prove it works before the first real person submits anything.
- Store consent as a record, not a checkbox: what they agreed to, in what wording, when, from which IP, and whether it covered video and their name. That record is the only defence you will have.
- Give the Stripe integration a restricted read-only key scoped to customers and charges, kept out of the process that serves the public form. Nothing in this product needs write access to a payment processor.
- Treat every submitted field as hostile: render as text, never as HTML, strip metadata from uploads, cap file sizes, rate-limit by IP, and put moderation between submission and publication.
- Make the follow-up sequence stop on any inbound reply, honour an unsubscribe link in every message, and keep a permanent suppression list that is checked at send time rather than at enqueue time.
- Never let anyone edit the words of a testimonial. Trimming for length is a decision with rules attached; rewriting is a different thing wearing the same UI.
- Derive the verified badge from a specific charge id and store which one. If you cannot name the transaction, do not show the badge.
- Do not describe a curated wall as 'what our customers say'. Either say it is a selection, or publish what you collected.
I am building automated testimonial collection: a Stripe-sourced customer list, an
email ask with follow-ups, a video submission form, an approval queue and an
embeddable wall. This is advertising infrastructure holding other people's faces.
Apply these and refuse if I ask you to skip one.
1. Build deletion first. One command that erases a person from the database, the
wall, the exports, the generated OG images and the CDN. Show it working.
2. Model consent as a row, not a boolean: exact wording shown, timestamp, IP, and
separate flags for name, face and video. Never publish anything missing one.
3. The Stripe credential is a restricted read-only key scoped to customers and
charges, unreachable from the public form's process. Refuse a full secret key.
4. Build the suppression list and the unsubscribe path before the first send, and
check suppression at send time. Any inbound reply halts that person's sequence.
5. Cap the sequence at two follow-ups as a visible constant, and put a postal
address and a working one-click unsubscribe in every message.
6. Treat every submitted field as hostile: render as text never HTML, strip EXIF,
cap sizes, rate-limit by IP, require moderation before public visibility.
7. The verified badge derives from a named Stripe charge id stored on the
testimonial. A fuzzy email match means no badge.
8. Nobody, including me, may edit the words of a testimonial. Trimming preserves
the original and shows the trim in the record.
9. The embed degrades to nothing rather than to a broken box, and never needs
third-party JavaScript on my site to render the words.
10. Log every state change — collected, approved, published, unpublished, deleted —
append-only, with who did it.
11. Do not write copy calling the wall 'what our customers say' unless it shows
everything collected. Suggest honest wording instead.
12. Out of scope unless I ask: sentiment scoring, AI-written testimonials,
incentive campaigns, review-site syndication.
13. If I ask you to auto-publish without moderation, or to hide negative responses
while implying completeness, stop and tell me why that has a rule number.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
Once a schedule is emailing people, or a badge is making a factual claim. Sixteen dollars a month buys deliverability you did not have to earn, a submission flow that has already met real spam, video hosting with a takedown path, and somebody else's name on the compliance surface. The comparison that matters is not the subscription against your weekend — it is the subscription against one afternoon spent proving to an unhappy customer's solicitor that you had permission to publish her face.
$16/mo is cheaper than your weekend.
The asset is the testimonials plus the consent records, and they only travel together — a quote you cannot prove permission for is a liability, not a testimonial. Keep both in your own database and export them as one bundle: text, media, consent wording, timestamps, the charge id behind any badge. On the way out, revoke the Stripe key first, then stop the sequences, then take the wall down — in that order, because a dead product still emailing your customers is the worst possible ending. If you move to a hosted tool, expect to re-collect consent rather than import it.
Questions
This is a $16 tool. Is YOUR FUNERAL not a bit much?
The price has nothing to do with it and the wall itself is genuinely a weekend. The verdict comes from the three verbs Proofling adds to a testimonial wall: it reads your payment processor, it emails your customers on a schedule, and it publishes claims about who bought what. Any one of those alone would be DEMO ONLY. Together they mean your marketing page makes assertions your code has to be able to back up.
Does the FTC review rule really apply to a testimonial page on my own site?
It applies to testimonials used in advertising, and a wall of proof is advertising. The parts most relevant to a homemade build are the prohibitions on fake or misattributed testimonials and on misrepresenting a curated selection as representative. Approving only the good ones is not itself illegal — implying that what a visitor sees is what your customers said, when you filtered it, is where it goes wrong. Say it is a selection and most of the problem disappears.
How does this differ from your Testimonial.to and ShowTrust entries?
Testimonial.to is about likeness and the obligation you take on by hosting someone's face. ShowTrust is about moderation and the deletion path you did not build. This one is about automation and claims: a cron that contacts people who did not ask, and a badge that asserts something about a purchase. It is the same wall with a machine in front of it and an advertising claim on top.
Is there open-source prior art?
Not really — nothing well-maintained does automated collection plus consent records plus an embeddable wall. The wall is trivial to write; the missing pieces in every DIY attempt are exactly the ones this page is about, and no repo will hand them to you.
- FTC — Consumer Reviews and Testimonials Rule: questions and answers
- 16 CFR Part 465 — Rule on the Use of Consumer Reviews and Testimonials (eCFR)
- FTC's Endorsement Guides: what people are asking
- CAN-SPAM Act compliance guide for business (FTC)
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-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice