LiveTrader is a white-label platform where forex brokerages get their own fully branded trading environment without building one from scratch. Each tenant gets a client-facing webtrader on their own domain, a back-office CRM, SSL provisioned automatically, and their own isolated configuration. The tenant owns the brand and the client relationship. LiveTrader runs the infrastructure.
The product has gone through two major versions, and I have been across both.
LiveTrader V1 is the live production version. It launched in June 2025 and by April 2026 had 41 tenants onboarded across roughly 10 months. Those tenants generated 864 registered end-users and processed $111M+ in approved transaction volume across 483 transactions. The focus is brokerage: clients register, complete KYC, deposit funds via crypto or card, open trading accounts, and trade forex, stocks, crypto, commodities, and indices. There is no prop firm module in V1. Pricing in V1 was not fixed: each tenant arrangement was handled individually rather than through a standardised pricing structure.
LiveTrader V2 is the version currently in development. It expands the platform significantly: multiple trading accounts per client, a PropFirm module alongside the core brokerage product, a restructured frontend built in React 19 with Vite, and a standardised pricing model at $700/month. V2 already has tenant owners in the queue waiting to onboard. V2 introduces explicit feature flags where V1 used a settings JSON blob, and the wallet becomes the central clearing system for all financial movement rather than funds flowing directly between payment methods and accounts.
I was the TPM responsible for V1 delivery and onboarding, and I am shaping V2 product decisions.
My Role
Managed full tenant onboarding for all 41 V1 tenants: MT4/MT5 server credential collection, subdomain and custom domain provisioning, SSL setup, crypto wallet configuration, per-tenant SMTP setup, and KYC flow configuration
Owned the onboarding intake process: moved all technical requirements upstream so configuration details were collected before setup began rather than discovered mid-onboarding
Managed the real-time price infrastructure: OANDA upstream feed routed through an internal Node.js/Socket.io proxy (surdonline) that fans out to all connected tenants without reconnecting per-tenant
Coordinated the 10-role access system across tenant operations: superadmin, tenant_admin, manager, staff, support, affiliate, lead, user, customer
Led product decisions on V2 architecture: wallet-as-clearing-system, multi-account per client, PropFirm challenge flows, demo vs trial distinction, and the V2 pricing model
Defined the V2 prop firm challenge system: one-step, two-step, and three-step challenges with configurable profit targets, drawdown limits, time rules, and add-on options like higher leverage or faster payouts
Acted as the main point of contact for tenant issues: MT4 bridge connectivity, account provisioning errors, deposit flows, payment gateway integration, and Telegram notification setup
Architecture
V1 is a Laravel monolith with a Blade/Vue frontend and a MySQL database. Multi-tenancy works through a company_id on every record. The ResolveTenant middleware reads the subdomain or custom domain on each request and scopes all data and configuration to the right tenant. No cross-tenant access is possible.
Each tenant's feature set in V1 is controlled by a settings JSON blob on the companies table. This covers whether live prices are enabled, whether MT4 accounts can be created, which crypto wallet addresses to use, which page design variant to show, whether the affiliate programme is active, which Telegram groups receive notifications, and more. Configuration is additive and lives in that blob rather than in rigid columns.
Live prices are sourced from OANDA via surdonline, an internal Node.js/Socket.io server that connects to OANDA once and fans out to all connected clients. Every tenant on a shared server sees the same underlying price feed. Tenants without live_api enabled run on simulated prices. Real-time in-app notifications go through Pusher with Laravel Echo.
Domain and SSL provisioning works through the Forge API. When a tenant's domain is registered, the app creates an nginx config via Forge pointing at the shared application root, then triggers Let's Encrypt for SSL. A background job polls Forge until the certificate becomes active. The tenant only needs to point their DNS A record to the server IP.
V2 restructures the frontend into a separate React 19 TypeScript app compiled via Vite into Laravel's public folder. Splade handles the admin UI. The wallet becomes a first-class model: every financial movement routes through it before reaching a trading account or payment method, which keeps the audit trail clean and isolates the bonus system.
Key Decisions
Configuration as a JSON blob per tenant, not a rigid schema
V1 stores all tenant configuration in a single settings JSON blob on the companies table. This made it fast to add per-tenant features without database migrations and meant onboarding a tenant with unusual requirements did not require code changes. V2 introduces explicit feature flags with defined types to address the drift and auditability issues that came from the blob approach.
One shared price feed fanned out to all tenants
Rather than each tenant connecting to OANDA independently, surdonline connects once and fans out to all connected clients on the server. This kept infrastructure costs low and made adding new tenants cheap. The risk is that all tenants share the same feed: if surdonline has issues, everyone is affected at once. That risk was accepted in exchange for simplicity at V1 scale.
Automating domain SSL provisioning
In early V1, connecting a tenant's custom domain required manual server work on every onboarding. I worked with the team to automate this using the Forge API: the tenant submits their domain, the app provisions the nginx config and triggers Let's Encrypt, and a background job handles the polling. DNS propagation lag still causes support tickets, but the manual intervention step is gone.
Moving all configuration requirements upstream in onboarding
The most common source of onboarding delays was discovering a missing credential or decision mid-setup: MT4 server IP not ready, crypto wallet addresses missing, SMTP credentials not available, KYC flow preference unclear. I restructured the intake process so all of this was collected before any technical work started. It did not eliminate the delays, but it moved them to a point where they did not block setup.
Building V2 PropFirm around how leading prop firms operate
The V2 prop firm challenge system was designed around how established firms like FXIFY run their businesses. One-step, two-step, and three-step challenges with configurable profit targets, drawdown limits, time rules, and add-ons like higher leverage or faster payouts. The goal was that a tenant launching a prop firm on LiveTrader should have a product that matches what traders already expect from the category.
Challenges
DNS propagation and SSL cert issuance caused delays on every onboarding
Each tenant gets two to three custom domains. Records are created via Forge and SSL via Let's Encrypt, but propagation lag was a constant source of support tickets. We could automate the provisioning but not the DNS wait, so I built the expected delay into the onboarding timeline so tenants were not surprised by it.
MT4 server credentials arrived late or incorrectly formatted
Tenants with MT4 enabled had to provide their own MT4 server IP and login credentials. The platform does not host MT4; it integrates with the broker's existing server. Getting those credentials correctly and on time was a blocker on almost every MT4 onboarding. Moving the credential collection upstream helped, but some brokers did not have their MT4 server ready when they signed up.
Crypto wallet provisioning required per-chain addresses from every tenant
Tenants accepted deposits via up to ten crypto networks: BTC, ETH, USDT on ERC20 and TRC20, USDC, BNB, XRP, SOL, LTC, and TRX. Each network required its own wallet address from the tenant. Missing even one address caused silent deposit failures for clients on that network. I added wallet completeness checks into the go-live criteria so tenants could not launch with gaps.
Every broker had a different opinion on when to run KYC
Some tenants wanted KYC at registration, some at first deposit, some at withdrawal only. The platform ended up with separate configuration flags for each variant: send_deposit_kyc_required triggers a KYC prompt on the first deposit attempt, send_kyc_required_on_approval triggers it at admin approval time. The variation in broker preferences was too significant to pick one default and enforce it across everyone.