Case study · Production deployment · Financial operations
A complex financial workflow translated into one production platform: signup, checkout, trader accounts, realtime market data, risk enforcement, payouts, and the internal back office, designed, deployed, and operated end to end.
A futures evaluation business sells a simple promise: pay for an evaluation, trade within the rules on live market data, get paid if you succeed. Operating that promise is not simple. Checkout, provisioning, live trading, risk enforcement, payouts, affiliate tracking, communications, and internal administration all have to agree about what is true at any moment.
Run that on disconnected vendor portals and spreadsheets, and every gap becomes operational risk: a paid customer without an account, a breached account still trading, a payout reviewed against stale numbers. The hard part was not any single screen. It was keeping one reliable operational state across money, accounts, and live decisions.
Product workflow
A dashboard built around the evaluation: live balance and performance, the objectives governing the account, progress toward qualification, and clear signals when a rule was at risk, with purchases and email in the same place.
An internal console over the same data: account operations, payment status, lifecycle controls, payout review, risk and rule administration, email and retention workflows, affiliate management, and the audit trail behind privileged actions.
Admin command center
Trader dashboard
Account detail and objectives
I designed, built, deployed, and operated the platform supporting the business: product definition, interface design, application architecture, the data model, backend services, the payment and trading-data integrations, risk and lifecycle logic, internal tooling, deployment, and incident response. It was not handed off after launch; I was responsible for how it behaved when customers, money, and live decisions moved through it.
AI coding agents accelerated implementation inside a constrained workflow: repository context (CLAUDE.md, an extensive architecture reference), scoped task plans, diff review, targeted tests, and production verification. The decisions and the accountability stayed human.
Payments and billing
Tokenized checkout, recurring billing, entitlements, and webhooks backed by a durable event ledger.
Provisioning and lifecycle
A six-step provisioning state machine and one shared definition of account state, purchase through archive.
Trading data and risk
A dedicated service projected the vendor's live stream into Postgres and drove rule monitoring.
Payout operations
Qualification rules as pure functions, amounts frozen at creation, and an operator review workflow.
Communications, retention, and CRM
Transactional and campaign email, automations, and a CRM view over platform data. Velocity Intelligence (VI Pulse, Sentinel, Debrief) added AI-assisted trader analysis; VELOBOT automated community operations.
Admin controls and auditability
Role gates enforced at the edge and per route, an append-only audit log, and read-only forensics scripts.
Retention intelligence
Email hub
Trading rules administration
Payment events are durable state transitions, not disposable callbacks.
Every webhook lands in an events table keyed by a content hash of the raw body, so duplicate deliveries become no-ops instead of double-charges. Processing runs off the request path, with an inline fallback and replay sweeps.
ResultRedelivery, retries, and outages could not corrupt payment state.
Eligibility and rule logic lives in pure functions, separated from the routes that gather data.
Payout eligibility, entitlements, affiliate attribution, and lifecycle state are deterministic functions: readable, reusable, testable without mocking infrastructure.
ResultThe most consequential logic is the most tested and the easiest to reason about.
Monetary facts are captured at the moment of decision, never recalculated from changing state.
Payouts store amounts in integer cents at creation, and affiliate commission rates are snapshotted at conversion. Changing a configuration later cannot rewrite what was decided.
ResultFinancial history stayed stable, auditable, and defensible.
Account state has exactly one derivation, shared by every surface.
State was originally computed inline at five render sites, and they drifted. It became a nine-variant discriminated union with a single derivation function and a documented rule about allowed inputs.
ResultDashboards, jobs, and operator screens stopped disagreeing about what an account was.
Critical state, constraints, security, and financial records live in one relational database.
Schema as timestamped migrations, row-level security on user-facing tables, transactions around state transitions, realtime publications for live dashboards. Services stay stateless; Postgres holds the truth.
ResultOne shared source of operational truth.
One web application served both experiences; everything slow, streaming, or scheduled ran outside the request path.
Velocity platform architecture
Experiences
Application
Async processing
Data & state
External services
The payment event path
Provider event arrives
payment or platform webhook, raw payload
Durable receipt
keyed by content hash; redelivery is a no-op
Queued processing
off the request path; inline fallback if the queue is down
State transition
account, subscription, and entitlement updates in a transaction
Audit and reconciliation
replay and health sweeps catch anything missed
The launch-day schema cutover dropped the logical-replication publication that live dashboards depended on: balances froze while money and trading kept moving. The exact production migration path had never been rehearsed against the launch baseline. Diagnosed from replication state, restored the same day by migration, written up. The durable change: schema-drift logging and a launch checklist runbook.
A read-then-write usage counter let a promotion code be redeemed twice under concurrency. The fix: atomic reserve, commit, and release SQL functions, with the same compare-and-set pattern now guarding recurring-billing retries.
The lasting habit from both: production questions get answered by read-only forensics scripts, not by clicking around a live financial system.
Velocity launched publicly in May 2026 and ran the firm's operations through July: 86 registered platform users, real purchases, evaluations on live market data, payout reviews, and support, all through one platform, with financial and account decisions leaving durable records.
The evaluation business was wound down in July 2026 because of liquidity and operating constraints, and the company began pivoting toward software products. The software did what it was built to do through the whole operating period; the wind-down itself ran through the platform's own lifecycle machinery, with new purchases disabled cleanly.
CI with the existing test suite as a merge gate, instead of local runs and push-to-branch deploys. Coverage beyond the pure decision kernels, especially the heavy admin surfaces. A synthetic-data staging environment that rehearses exact production migrations, which is what the launch-day incident called for. Earlier separation of a few service boundaries that grew inside the web application. Each is scoped by having operated the system, not by hindsight alone.
The platform is a four-workspace Turborepo monorepo: the Next.js web application (trader and admin surfaces plus the API layer), a worker service for queued jobs, a realtime service consuming the vendor's market-data stream, and a shared package holding typed queue contracts, the vendor API client, and lifecycle logic.
For scale context only: the web application exposes 237 API route handlers, the schema spans 83 tables under 69 active migrations with 120 row-level-security policies, and the history is 878 commits on the main branch, merges included. The counts matter as a proxy for the surface area designed, built, and operated, not as an argument by volume.
Eight typed BullMQ queues with Zod payload schemas carry webhook processing, notifications, certificate generation, account syncs, and resumable email campaign sends. Ten Vercel cron jobs plus worker-scheduled crons, gated by an endpoint allowlist, handle rollups, replay sweeps, and health checks.
74 targeted test files exercise the pure decision functions (payout eligibility, queue payload schemas, webhook signature verification) as plain node scripts, without a test framework. Deployment is Vercel for the web application and Railway for the worker and realtime services (multi-stage Docker, non-root) with staging and production branches. The honest gaps: no CI pipeline, no coverage measurement, and largely untested heavy UI surfaces. Those would be the first fixes with a second engineer on the team.
Velocity Intelligence
VI Pulse
