build.allanninal.dev

Part 5 of 7 · Testimonial collector series ~4 min read

How a testimonial gets published

A quote that has cleared both gates is approved, but approved isn’t the same as live. The last step turns an approved row into something your website can actually show — a small, clean file with the quote and the credit exactly as the customer chose. Just as important, this step works in reverse: a customer who changes their mind can update their credit or pull their quote entirely, and the site reflects it on the next build. Consent here is a thing you can take back.

Key takeaways

  • An approved quote is written to a clean JSON file in S3 that your static site reads at build time.
  • The credit is rendered exactly as the customer chose — name, first name, initials, or anonymous.
  • A customer can update their credit later; the next build picks up the change.
  • A customer can withdraw consent; the quote drops from the file and the site on the next build.
  • Every publish, update, and withdrawal is logged to the audit trail.

Three things that happen to an approved quote

Three things an approved quote can do A diagram showing one input on the left flowing through a small panel, then branching into three action paths. Far left: an "Approved quote" box showing a typical approved row — the clean quote, the customer's chosen credit, and the date approved — with three action placeholders below: Publish, Update credit, Withdraw. The middle column shows the three branches. Branch one, Publish: a Function URL Lambda writes the quote and its credit into the published JSON file in S3 that the website reads at build time, sets the row's state to live, and writes a published event to the audit trail. Branch two, Update credit: the customer reopens their page and changes how they want to be named; the Lambda rewrites that one entry in the published file with the new credit and logs the change. The quote text itself isn't changed. Branch three, Withdraw: the customer taps a withdraw link; the Lambda removes their entry from the published file, sets the row's state to withdrawn, and the quote disappears from the site on the next build. The right side shows the convergence: every action writes a row to the tc-audit DynamoDB table with timestamp, the customer, the action, and notes. A note at the bottom: publishing is reversible — a withdrawal drops the quote on the next build, and the consent record stays in the audit trail. Approved quote quote, credit, date [Publish] [Update credit] [Withdraw] Action 1 Publish • Write quote + credit into the published JSON in S3 • Site reads it at build • State set to live Action 2 Update credit • Customer changes how they are named • That one entry is rewritten; text unchanged Action 3 Withdraw • Entry removed from the published file • Gone from the site on the next build Audit trail DynamoDB tc-audit timestamp · customer action · credit notes Publishing is reversible — a withdrawal drops the quote on the next build; the consent record stays.
Fig 5. Three things that happen to an approved quote. Publish writes it into the file your site reads; Update credit rewrites just the credit; Withdraw removes it on the next build. Every action is logged to the audit trail.

Action 1: publish to a file your site reads

When a quote is approved, a Lambda writes it into a single JSON file — s3://tc-published/testimonials.json — that holds every live quote. Each entry is small and clean: the quote text, the credit (rendered exactly per the customer’s choice), the moment type, and the date. Your website reads this one file at build time and renders the quotes wherever you want them — a homepage strip, a wall of love, a proposal template. Because the site is static and reads a plain file, there’s no database call on every page view and nothing to keep running. The published file is the clean boundary between the collector and your site: the collector owns the file, the site just reads it.

Keeping everything in one versioned file (S3 versioning is on) has a nice side effect: if a bad edit ever slips in, you roll the file back in one click and the next build is clean again.

Action 2: update the credit

People’s preferences change. Someone who said “first name only” in March might be happy to use their full name in June, or the other way around. The link in their original email keeps working, so a customer can reopen their page any time and change how they’re credited. The Lambda rewrites just that one entry in the published file with the new credit — the quote text itself never changes — and the next build shows it the new way. Honoring this in one tap, with no email to support, is the kind of small respect that keeps customers comfortable being quoted at all.

Action 3: withdraw

The most important action is the one you hope is rarely used: withdrawing. Every published quote carries a withdraw link. One tap removes the entry from testimonials.json, flips the row’s state to withdrawn, and the quote is gone from the site on the next build — no questions, no friction. Crucially, the consent and withdrawal are both kept in the tc-audit trail. So even after a quote comes down, you can still show that the customer once consented and later chose to withdraw, with timestamps for both. Consent you can’t walk back isn’t really consent; this step makes sure it’s a door that opens both ways.

That completes the loop: a happy moment is spotted, one ask goes out, a reply is tidied into a clean quote, two gates sign it off, and an approved quote is published — reversibly. The next post adds up what all of this costs to run, and the last one is the engineering reference.

All posts