# Build brief — a focused alternative to ShowTrust

> **Verdict:** Yes, for personal use · **Buildability:** 90/100 · **Category:** Testimonials
> **Source:** https://www.canitbevibecoded.com/showtrust
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from ShowTrust. Verify current pricing and capabilities before acting.

## Context

**ShowTrust** — A shareable link that collects testimonials, and a widget an agent can install for you. It currently costs $4.99/mo.

A submission form, an approval queue, and a grid of cards you can embed elsewhere. There is no algorithm here and no network effect · an agent will produce a working version, same as it will for the $25 and $29 tools in this category. The catch is the same one Eloqra has: the hosted version is free for a single site, with no cap on testimonials, so you'd be spending a contained effort and a hosting bill to replace zero dollars. Worth building if you want the data on your own box or you enjoy the exercise. Not worth building to save money, because there isn't any to save.

This brief describes a focused, single-operator replacement for the part of ShowTrust that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

## What you are building

A public page collects a name, photo, star rating and quote; you approve them; approved ones render as an embeddable wall on your site.

- Build a focused single-user workflow with real persistence, search, and export.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- A small always-on host.
- Somewhere to put uploaded avatars (local disk is fine).

### Non-functional

- Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
- Security: server-side secrets, validated input, and no credentials in the client bundle.
- Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
- Portability: the operator can export their data and leave without losing it.

## Implementation brief

Build me a testimonial collection and display tool. Requirements:

- Stack: one Node + TypeScript service (Fastify) with SQLite via better-sqlite3 and local disk
  for uploads. No Docker, no separate frontend build, no customer accounts.
- A public collection page at /c/:slug · name, role, company, avatar upload, 1-5 star rating,
  and the quote. Each field individually toggleable per project from a config row. Submissions
  land as pending. Show a thank-you state after submit.
- An /admin page behind basic auth from .env: pending queue with approve/reject, plus pin and
  delete on approved ones. Nothing is public until approved.
- An embeddable wall: GET /widget.js injects the approved testimonials into any page via one
  script tag plus a div, rendered into a shadow DOM so the host page's CSS can't leak in.
  No iframe.
- Offer three layouts (masonry, single-column list, horizontal carousel) and read layout,
  accent colour, light/dark theme and card corner radius from data- attributes on the tag.
- Server-render the widget HTML and have the script fetch it, so the testimonials are in the
  response rather than assembled client-side. Cache it with a short max-age plus
  stale-while-revalidate.
- Render every approved card in that response and hide the ones past a configurable initial
  count, then have Load More just unhide them · no second request, one paint, and the full set
  is in the HTML for crawlers.
- Drive all sizing from CSS custom properties on the container rather than per-element inline
  styles, so one stylesheet covers every layout and card style.
- Avatars resized server-side to 128px squares on upload with sharp; reject files over 5MB.
- Count impressions and click-throughs in SQLite · fire an impression only after the wall has
  been intersecting for one second, latch it so it can't fire twice per page load, and filter
  obvious bot user agents server-side.
- Rate-limit submissions per IP and add a honeypot field, because a public form will get spam.
- Ship a README with the paste-in snippet and VPS deploy steps behind TLS.
- Deliberately out of scope: video testimonials, importing from other platforms, team seats,
  and email notifications.

## Delivery standard

- Inspect the repository first, then write a short implementation plan before writing code.
- Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
- Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
- Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
- Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
- Add structured logs around every external call and return actionable errors without leaking sensitive details.
- Write unit tests for the core logic and one automated test of the main user journey.
- Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

## Acceptance criteria

- [ ] A clean install starts the app using only the README and .env.example.
- [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
- [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
- [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
- [ ] Tests, type checking, linting, and a production build all pass with no ignored failures.
- [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

## Non-goals

Do not build these, and do not claim to have replaced them:

- A free tier · one site with uncapped testimonials costs nothing hosted, so the DIY build starts out behind on price.
- The install itself · an agent can provision the account from your email alone, get working credentials in the same response, create the project and paste the snippet into your framework, with the human only clicking a claim link afterwards · your own build is something you have to go and deploy.
- The design surface you'd otherwise hand-build · multiple layouts, eight card styles, colour palettes, and sliders for width, spacing and radius, all previewable instead of CSS-tweaked by hand.
- Did-it-work data · impression and CTA-click tracking with click-through rate and which domains your wall is actually being viewed on.
- The last 20 percent is sync, migration fidelity, speed, and edge cases.

## What you still own after launch

- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.

## Risk

**Manageable.** A personal version is realistic if you test the critical journey and keep reliable backups.

Editorial confidence in this assessment: medium. No independent one-shot implementation is linked yet.

---

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/showtrust