Agents In Use
What’s new todayLast update
499 additions

How to use Claude to finish a paid message board

The creator finished an inherited message board with Claude Code and describes version-checked payment activation, refunds, and substantial performance and security work.

TRY A BOUNDED VERSION

Prompt to try

Editorial adaptation, not the source author’s exact prompt. Replace bracketed inputs and review tool permissions first.

Help complete [inherited paid message-board project]. Inspect [existing code] and implement [remaining requirements]. Use version-checked activation for competing [Stripe] payments, refunds for losing submissions, and idempotent webhook processing. Identify performance, security, and privacy work for my review.

What happened

The author reports completing the site with Claude Code and describes an idempotent payment activation flow that refunds competing submissions when the current post has changed.

Reported by SayThatSh on Hacker News

How the agent did it

  1. Take over the half-finished project after troubleshooting it.
  2. Build the rest of the message board with Claude Code.
  3. Work on performance optimisation and security hardening.

Where a person stepped in

The author describes substantial performance, security, and privacy work but does not specify code review or test steps.

A person approved each step before the agent continued.

A paid message-board creator described taking over a half-finished project after the original development team stopped delivering the work. They had spent substantial time troubleshooting and decided to take full responsibility. Claude Code helped them finish the site, but the author says roughly half their building time went into performance optimisation, security hardening, and alignment with European and Californian privacy standards.

The finished payment flow handles competing submissions with optimistic locking and automatic refunds. At payment initiation, the current post version is stored in Stripe PaymentIntent metadata. When the successful-payment webhook arrives, an atomic PostgreSQL update checks that version before activating the replacement. If another submission has already won, the payment is refunded and a WebSocket notification explains what happened.

The account also describes a per-user Redis lock to prevent double submissions and an idempotent activation path for Stripe webhook retries. These are reported implementation details, rather than evidence of independent security or compliance certification. The author separately drafts technical and promotional writing with LLMs, then edits and fact-checks it where relevant. Who it's for: developers inheriting unfinished applications who can devote attention to payments, concurrency, and operational behavior alongside agent-assisted coding.

Prompt
Suggested prompt (written by Agents In Use, not the author's)

Source: Hacker News · SayThatSh

Frequently asked questions

How does the board handle competing payments?

The first completed payment wins activation. A version-checked PostgreSQL update detects a replaced post, triggering a Stripe refund and a WebSocket notification for the losing submission.

How much work went beyond code generation?

The author says roughly half their building time went into performance optimisation, security hardening, and alignment with GDPR and Californian privacy standards.

More details

Remaining steps

  1. Work on alignment with European and Californian privacy standards.

About this account

Claude Code helped complete the inherited project; the author retained hands-on responsibility for the broader build.

Platform: Hacker News. Attribution: https://news.ycombinator.com/item?id=47420963. Prompt: Suggested (written by Agents In Use, not the author's). Sourced by the Agents In Use pipeline.

Credit: SayThatSh on Hacker News

Source published 18 Mar 2026

Source checked 14 Oct 2026

Tools and topics

Claude Code · Stripe · PostgreSQL · Redis · WebSocket

Payments · AI coding · Concurrency

Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.