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.
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.
Reach people exploring AI agents
See placements →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 NewsHow the agent did it
- Take over the half-finished project after troubleshooting it.
- Build the rest of the message board with Claude Code.
- 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
- 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.