Beta Launch Checklist

Everything required before accepting paying users, organized by category. Each item is marked:

• ✅ Done, verified — confirmed in this codebase/pass, nothing left

to do.

• ⚠️ Done, needs a human action this codebase can't perform itself —

the code/config is ready; something outside this environment (a real credential, a live account, a production infrastructure decision) still needs to happen.

• ❌ Not done — a real, named gap.

This list is the executive summary; every item links to the document with the full detail, methodology, and reasoning behind the checkbox.

1. Core product

• ✅ Subscription system (trial, Starter/Professional/Enterprise,

monthly/yearly, upgrade/downgrade, cancel, usage limits) — docs/BILLING.md.

• ✅ Onboarding (setup wizard, broker connect, first copier, guided

walkthrough) — docs/ONBOARDING.md.

• ✅ Live copier management (start/stop/pause/resume/emergency-stop,

health, latency, reconnect, logs).

• ✅ Risk management (global/per-account limits, daily loss, drawdown,

max trades, position sizing) — docs/RISK_PROFILES.md.

• ✅ Trade copier features (all copy topologies, symbol mapping,

multipliers, reverse copy, partial close, pending orders, magic number/comment filtering) — docs/TRADE_FILTERS.md.

• ✅ Dashboard, notifications (Email/Slack/Discord/Telegram/SMS) —

docs/ALERT_SYSTEM.md. Push notifications: ❌ architecture-ready, no vendor configured — not required for launch, named explicitly so it's not discovered as a surprise.

• ✅ Administration panel (users, orgs, brokers, monitoring, audit,

analytics/revenue, subscription cancel/reactivate) — docs/ADMINISTRATOR_GUIDE.md.

• ✅ Security features (2FA, API keys, sessions, audit log, rate

limiting) — docs/SECURITY_REVIEW.md.

2. Broker integrations

• ✅ MT5, TradeLocker, Tradovate, DXtrade, cTrader, Match-Trader — all

code-complete, all with real automated test coverage (474/474 tests passing) across every requested capability (login, account, balance, equity, positions, pending orders, market orders, close, modify SL/TP, reconnect, error recovery, latency instrumentation) — full matrix in docs/BROKER_INTEGRATION_REPORT.md.

• ⚠️ **No connector has been exercised against a real/demo broker

account in this environment (no credentials, no network access to broker servers here) — this is stated plainly in `docs/BROKER_INTEGRATION_REPORT.md` and was true before this pass, not introduced by it. Required before launch**: run that report's Validation Checklist against a real demo account for every broker you intend to support at launch, using real credentials someone on your team provides.

• ❌ Rithmic: wire transport not connected to a live gateway at all

(not just untested — genuinely unimplemented pending real developer access) — see docs/RITHMIC_TRANSPORT.md. Do not offer Rithmic at launch unless this is completed first.

3. Performance

• ✅ Local, synthetic Copy Engine load testing at 100-10,000 simulated

users — real numbers, real bottleneck identified (single-process throughput flat to ~1,000-2,000 simultaneous events, then degrading) — docs/STRESS_TEST_REPORT.md.

• ❌ No real database load testing — the local test deliberately

never touched the real Supabase project (a shared dev resource, not something to load-test without its owner's explicit go-ahead). Required before launch at meaningful scale: real load testing against a staging (not production) database, specifically to measure connection-pool behavior and real query latency under concurrent write load — the single biggest unmeasured variable in this report.

• ❌ No sustained/soak testing — only burst-and-measure-once was

performed.

• ❌ No multi-process/horizontal CopyWorker sharding has been built

— docs/STRESS_TEST_REPORT.md gives you the numbers to plan shard boundaries around, but the actual sharding logic (assigning users/orgs to worker instances) doesn't exist yet. Required before onboarding enough simultaneous users to exceed one process's ~1,000-2,000-event flat region — not necessarily required for an initial beta with a modest user count.

4. Security

• ✅ Authentication/JWT, authorization (RLS on all 47 tables), SQL

injection, XSS, CSRF, secrets/env-var hygiene — all reviewed and confirmed correct, no code changes needed — docs/SECURITY_REVIEW.md.

• ✅ Encryption (AES-256-GCM broker credentials, SHA-256 API keys) —

reviewed with two honestly-documented, non-blocking gaps (no key rotation tooling, no AAD binding).

• ❌ `npm audit`: 13 vulnerabilities (2 critical, 4 high), all

transitive dependencies of metaapi.cloud-sdk (axios, crypto-js, lodash, and others). Not auto-fixed — the only available automated fix is a six-major-version SDK downgrade, which this environment cannot safety-test against a live MT5 account. Required before launch if MT5 is offered: either wait for an upstream metaapi.cloud-sdk release with patched dependencies, or apply narrow package.json overrides and run a full live MT5 retest before trusting them — see docs/SECURITY_REVIEW.md §14 for the exact reasoning and staged remediation path. Do not skip this silently.

• ⚠️ No penetration test performed (code-level review only) — normal

for a pre-launch codebase-only pass; recommended before/shortly after a public (non-beta) launch, not blocking a beta with real users under an NDA/beta agreement.

5. Infrastructure & deployment

• ✅ Docker: web app + Copy Engine worker + nginx, all three services

now defined (copy-worker was missing entirely before this pass — fixed) — DEPLOYMENT.md.

• ❌ The Docker build itself has not been run in this environment

(no Docker available here) — the worker target's multi-stage semantics were reviewed carefully and the compose YAML was syntax-validated, but neither has gone through an actual docker build/docker compose up. Required before launch: run a real build, confirm both app and copy-worker start and pass their health checks, before this compose file is trusted in production.

• ✅ Supabase Cloud deployment steps, migration application, RLS —

documented and verified.

• ✅ Automatic recovery: restart: unless-stopped on every service;

each broker connector's own reconnect/backoff logic; Copy Engine session re-hydration on worker restart.

• ✅ Monitoring, logging, health checks — /admin/monitoring,

/api/health*, structured logging throughout, all reviewed and confirmed real (not stubbed).

• ❌ Disaster recovery plan has not been rehearsed — the plan

itself is real and complete (docs/DISASTER_RECOVERY_PLAN.md), but a written plan and a tested one are different confidence levels. Recommended before or shortly after launch: a real restore drill against a non-production project.

6. Documentation

• ✅ Deployment Guide (DEPLOYMENT.md), Administrator Guide, User

Guide, API Documentation, Disaster Recovery Plan, Backup Strategy — all written this pass, all real (no placeholder content), all auto-discoverable in-app via /docs.

7. Legal / business (outside this codebase's ability to verify)

Not reviewable from source code — confirm separately before accepting payment from real users:

• ❌ Terms of Service / Privacy Policy content accuracy (pages exist at

/terms//privacy — this pass did not review their legal content, only that the pages render; that's a legal review, not a code review).

• ❌ Regulatory considerations for a trade-copying product in your

target jurisdictions (this varies enormously by region and this codebase has no way to know your specific target market).

• ❌ Broker-side terms of service for automated/API trading — confirm

each broker you support actually permits this use pattern.

Summary: what genuinely blocks launch vs. what doesn't

Blocks launch for any broker you intend to actually support: that broker's own live demo-account validation checklist (§2) has not been run in this environment — this is not optional, it's the one thing no amount of code review substitutes for.

Blocks launch if MT5 is offered: the npm audit findings (§4) — at minimum, a documented decision (not silence) on the remediation path.

Blocks launch at any real production scale: the untested Docker build (§5) and unrehearsed DR plan (§5) — both are "probably fine, verify before betting the launch on it," not "known broken."

Does NOT block a small, invite-only beta with a handful of real users on demo/low-risk accounts: horizontal CopyWorker sharding (§3), real-database load testing (§3), a formal penetration test (§4) — all real, named, worth doing before scaling past a beta, not before starting one.