White-label trading platforms typically require weeks of setup time, dedicated integration support, and enterprise procurement timelines. For mid-market operators, legitimate brokerages and prop firms with real market knowledge but no infrastructure teams, that model put a proper trading environment out of reach. The product needed to compress the path from contract to live without sacrificing the tenant isolation, configurability, and reliability that serious financial operators require.
Overview
A confidential multi-tenant white-label trading infrastructure serving registered brokerages and proprietary trading firms. Each tenant gets a fully branded environment: a customisable landing page, a client-facing trading portal, and an admin back-office, all running under their own domain. The platform supports live trading across forex, crypto, commodities, equities, and indices with real-time price feeds, trade execution, KYC document handling, deposit and withdrawal processing, and per-tenant operational notifications.
The platform has been live since June 2025 and currently serves 18 commercial tenants with active environments, with 1,010 user accounts registered across all tenants and 1,164 trades executed on the platform to date.
As TPM, I owned the partner-facing side of the product: onboarding new tenants from contract to go-live, managing production incidents as the primary escalation point, and driving the roadmap decisions that reduced time-to-live and improved platform reliability.
My Role
Owned end-to-end partner onboarding: from contract through domain configuration, environment provisioning, settings validation, and go-live handoff
Led diagnosis and resolution of six recurring onboarding failure modes that were blocking new tenant go-lives, reducing provisioning from a multi-day process to a documented sub-hour flow
Managed production incidents as the primary escalation point, covering platform-wide outages, silent feature failures, and a tenant isolation breach in the notification layer
Defined and documented the reference baseline for tenant settings completeness, giving the team a health check any provisioning run can be validated against
Drove the roadmap decision to build a self-serve tenant controller that let sales onboard new brokers without waiting for an engineer, removing the biggest bottleneck between contract and go-live
Introduced a freemium acquisition model for new tenants: reduced signup friction, implemented meaningful limits, and added upgrade prompts at the points where tenants were hitting real growth constraints
Stakeholders
Broker and prop firm partners (tenant owners)
End traders (customers of each tenant)
Engineering team (provisioning and incident resolution)
Platform leadership (product direction and partner relationships)
Key Decisions
Freemium entry for tenants with limit-gated upgrades
Requiring upfront payment to evaluate a new trading platform is a high-friction ask for operators comparing multiple providers. A freemium plan lowered the barrier to entry and let tenants experience the product in a live environment before committing. Upgrade prompts were placed at the points where growth naturally creates pressure, user caps and feature unlocks, so the conversation is triggered by the tenant's own traction rather than a sales call.
Self-serve domain setup instead of manual DNS configuration
The original onboarding required manual DNS setup by the engineering team for every new tenant: configure the domain, point it to the server, wait for propagation, repeat if anything went wrong. The tenant controller allows operators to register or connect their own domain, select a theme, and have their branded environment live without any server-side intervention. This removed engineering as a bottleneck in the acquisition path.
Reference baseline for tenant settings validation
New tenants were going live with silent configuration gaps. Missing settings caused features to fail with no error message, so neither the tenant nor the engineering team knew anything was wrong. Rather than adding per-field validation to every onboarding step, the fix was to establish a reference tenant as the completeness standard. Every new provisioning run is compared against that baseline before the tenant goes live.
Challenges
Silent failure modes with no error surfacing
Several of the most damaging issues were ones nobody was reporting because the visible surface of the platform continued to function. A broken WebSocket connection meant real-time notifications were not reaching traders, but trades still executed over HTTP so no support tickets came in. A wrong API endpoint in the SSL service meant certificate generation was silently failing for every new onboarding. Finding these required proactive audits rather than waiting for an escalation.
Tribal knowledge onboarding with no fallback
Which commands to run, which settings to populate, what a healthy tenant configuration looks like: all of that lived in the heads of whoever had done the last onboarding. When a new tenant hit a failure mode not seen before, there was nothing to fall back on. Building the provisioning runbook and reference baseline was the thing that let the platform grow past the founding team.
Discovery
The platform started with the MD's own trading experience. He needed a way to automate his trades, found a developer to build the bot, and through that process saw firsthand how inaccessible good trading infrastructure was for serious operators who had the market knowledge but not the technical means to run a proper environment. Most of the product decisions that followed came directly from the tenant owners themselves: every feature request, every friction point, and every onboarding failure fed back into the roadmap. Discovery was not a structured research exercise. It was a continuous feedback loop from the operators using the product from day one.
Stakeholder Friction
Two recurring tensions shaped the roadmap. First, the engineering team regularly pushed back on client-requested features, arguing the feature did not make technical sense or added unnecessary complexity. The framing that resolved most of these was straightforward: this feature exists in every major trading platform for a reason, and our tenants expect to find it here. Second, UI/UX work consistently drifted toward clean, modern conventions that looked right but felt wrong to users. Traders are pattern-matched to specific interfaces. A chart toolbar that does not look like TradingView's creates confusion, not delight. Getting the design team to treat industry convention as the brief rather than a constraint took sustained feedback before it stuck.
Outcomes
Onboarding reduced from multi-day to sub-hour
Diagnosed six recurring failure modes blocking new tenant go-lives: a broken SSL provisioning endpoint, a seeding job that silently did not run for manually-created tenants, and undocumented settings that caused silent feature failures with no error output. Fixed three in the codebase and documented the rest as a reproducible checklist. New tenants now go live in under an hour on a predictable, validated path.
18 commercial tenants live on shared infrastructure
18 broker and prop firm environments running on a shared server with full tenant isolation, custom domain support, and per-tenant branding. That is up from a handful at platform launch in June 2025, with steady tenant growth as the onboarding process became reliable. Architecture sustained 8,900+ active sessions at peak load, which surfaced a Redis memory configuration issue that was diagnosed and resolved before it caused data loss.
Production incidents resolved without data loss
Managed several platform-level incidents as the primary escalation point, including a platform-wide outage caused by a Redis memory configuration issue, a silent real-time failure affecting all tenant environments that was not being reported because core trading still functioned over HTTP, and a tenant isolation breach in the notification routing layer. All resolved without permanent data loss or ongoing vulnerability.
Technology Decisions
Multi-tenant LaravelReal-time WebSocket (Pusher)Live price feeds (OANDA + Twelve Data, 233+ assets)AWS S3 (KYC and documents)Redis (sessions, queue, cache)Laravel Forge API (SSL + domain management)Cloudflare DNS APITelegram Bot APITradingView Charts
What I'd Change
User experience, from the ground up. The support questions that arrive most often today are not about missing features. They are about features that already exist but that users cannot find. The navigation assumes familiarity that new users do not have. If I were starting again, I would treat discoverability as a product requirement from day one, not a documentation problem to solve after launch. The feature set is strong. The problem is that nobody can find it.