Hardening an AI SaaS Revenue and Asset Pipeline

Engineering objective

System challenge

Harden the product’s asset, generation, credit, payment, authentication, and administration paths into durable, server-owned infrastructure suitable for production operations.

Constraints

Working within real limits

• ✕Uploaded campaign references could remain in temporary browser state rather than private storage
• ✕Credit accounting required stronger server-side ownership and atomic SQL RPC operations
• ✕Stripe payment fulfillment required idempotent ledger handling to protect revenue
• ✕Generation entitlements required durable provider-backed results before credit settlement
• ✕Release gates required runtime, persistence, security, and billing evidence in addition to build success

Architecture

Durable Asset & Idempotent Revenue Pipelines

Launch Readiness Sequence

Five Evidence-Based Deployment Gates

Approach

How it was built

1. 01

   Durable asset architecture: Moved campaign assets into private Supabase-backed storage, delivered assets through signed application routes, persisted generated images rather than relying on temporary browser state, passed reference images into generation workflows, and used durable asset URLs across generation paths.

2. 02

   Revenue integrity: Shifted credit deductions and additions to server-only SQL RPC operations, replaced non-atomic application-level balance changes with database-owned mutations, implemented idempotent Stripe webhook ledger handling, validated price lookup keys and server-side pricing inputs, protected first-purchase launch bonuses from repeated fulfillment, and added a prebuild environment check to fail missing production config before deployment.

3. 03

   Security and access: Mandated explicit grants on public database tables, tightened Row-Level Security (RLS) around authenticated and anonymous roles, enforced signed access for private asset delivery, browser-tested portal access, protected redirects, invalid credentials, and authenticated flows, and shifted the administration view away from static demo data toward live application metrics.

4. 04

   Verification: Completed 37 readiness tests across 9 test files, verified clean lint, passed TypeScript compilation, completed production build, confirmed zero moderate vulnerabilities in npm audit, verified protected-route redirection and invalid-login rejection in browser tests, and confirmed an authenticated reference upload reached private campaign asset flow while loading the 430-model catalog during the browser smoke path.

5. 05

   Release engineering: Separated application verification from external deployment configuration so database migrations, domain routing, and webhook delivery could be managed as explicit release gates.

Technical validation

Implementation evidence

Observable engineering evidence. Discipline: SYSTEMS HARDENING

Outcome

What was delivered

• Reworked critical asset, generation, billing, and authentication paths so product behavior was backed by durable infrastructure rather than interface-only state

• Private Supabase-backed campaign assets delivered via signed application routes

• Atomic SQL credit mutations and idempotent Stripe payment fulfillment protecting revenue integrity

• 37 tests passed across 9 test files, lint passed, TypeScript passed, production build completed, zero moderate vulnerabilities in npm audit

• Browser-tested protected-route redirection, invalid credential rejection, reference upload persistence, and authenticated 430-model catalog smoke path

• Defined explicit release gates for database migration, domain routing, and webhook delivery

Technologies

Stack and tools

Next engineering system