Manish Shetty

All systems

BCD

A sales, delivery and lifecycle-automation platform, released through one test gate

Walkthrough3:54
Role
Founder; AI Systems and Automation Lead, Phalanx Labs (2021 to present). Product owner and operator: I set what it must do and must never do, directed the AI agents, and tested and signed off every release.
Built with
Claude Code and Codex (AI coding agents); Stripe, Supabase, Resend, Meta Marketing API, MCP, Vercel.

How it works

From a payment to access, emails and reporting, with money decided on the server and one gate before every release.

  1. Checkout

    Stripe checkout, plus a one-click upsell charged to the saved card.

  2. Signed payment notice

    Access comes only from Stripe's signed webhook, never from a browser redirect.

  3. Checks before access

    Status, currency, every line item, total, customer and time must all match the offer. If in doubt, grant nothing and alert a person.

    A person decides

  4. Access and delivery

    Each payment event is recorded once, and a catch-up job replays any that were missed.

  5. Lifecycle email

    One policy for every send: bounces, complaints and unsubscribes stop everything, and nobody is offered the next product before opening the one they bought.

  6. One ledger

    Every report reads one definition of money; unknown traffic is never counted as organic.

  7. One release gate

    About 1,900 tests and 66 database suites must pass before anything ships.

    A person decides

The outcome

A sale is taken, checked, fulfilled and followed up with no manual step. Every release passes one gate of about 1,900 automated tests and 66 database test suites. A pre-launch review found six defects, and each was fixed the same day with a regression test (a test that stops the same bug coming back).

The problem

The company sells through a short offer ladder: an entry product, order bumps, a one-click upsell, a core offer at a time-limited price and a premium tier. Each step has its own price rules, deadlines and access, and each buyer's emails depend on what they bought and when. By hand, that's slow and error-prone. Built carelessly, it gives away access or charges the wrong amount.

What I decided

  1. Money is decided on the server. A browser redirect after payment proves nothing. Access comes only from Stripe's signed payment notification (a webhook), checked against what was offered.
  2. When in doubt, grant nothing and alert a person.
  3. One definition of money: a single ledger that every report reads from.
  4. The ad platform gets the conversion and nothing private.
  5. Every release passes one gate.

How it was built

The agents drafted the build plans and the code against these rules. I tested and signed off each release.

  • Payments: Stripe checkout, plus a one-click upsell charged to the saved card. Each payment event is recorded once, and a catch-up job replays any that were missed.
  • Checks before access: the payment's status, currency, every line item, total, customer and time must all match the offer. A refunded or disputed purchase can never flip back to paid.
  • Lifecycle email (Resend): one policy covers every send. Bounces, complaints and unsubscribes stop everything, sends are spaced out, and nobody is offered the next product before they've opened the one they bought.
  • Ad conversion tracking from the server, with personal fields wiped once sent.
  • An admin area with revenue, campaign, customer and operations screens, and a built-in manual explaining how every number is calculated. Traffic is split into paid, organic and unknown, and unknown is never counted as organic.

Results

  • One release command runs the type check, about 1,900 automated tests, 66 database test suites, the build, a check that private content hasn't leaked into the public code, and a scan for banned claims.
  • The tests catch money bugs. When the money logic was broken on purpose, 4 of 4 database changes and 1 of 1 code change were caught.
  • A simulated participant was followed for 106 days against a real local database.
  • A late or mismatched payment grants nothing, and a failed or stuck payment event alerts me within a minute. That alert exists because a payment event once failed silently and went unrecorded.
  • A separate AI review session audited the build before launch and found six defects, including private links leaking to the analytics tool, quality checks that let failures through, and a weekly report job that marked failures as done.

What I'd do next

Move the email schedule into one tested scheduler, and add step-by-step funnel reporting from the first click.

Screens from the build

BCD admin Operations screen in test-data mode listing open alerts, a refund needing access removal, an email awaiting delivery confirmation and a table of recent lifecycle emails
The admin Operations screen: failed payment events, undelivered emails and access changes that need a person, each resolved with a written note (demo data)
BCD admin Manual screen explaining the daily routine and what each admin screen shows
The built-in admin manual, which explains what each screen shows and how every number is calculated (demo data)
Terminal-style render of a passing npm run gate: type check, automated tests, build, client bundle check and compliance scans, ending with exit code 0
One release command runs the type check, the automated tests, the build, the private-content leak check and the banned-claims scan. A local run, condensed for legibility