Fund Deployment Playbook
This playbook is written for an individual trader, a small fund, or a prop desk standing the chart up on its own infrastructure, with no dedicated platform team. The sequencing matters more than any single technical choice: the common failure is building the whole stack before proving the first chart.
Phasing
Each phase ends in something observable. Do not start the next one until the previous one is visibly working.
| Phase | Done when | Typical effort |
|---|---|---|
| 1 · One chart | widget.ready() resolves and candles render from hardcoded bars | Hours |
| 2 · Real history | loadBars serves your source and scroll-back extends without gaps | 1–3 days |
| 3 · Live stream | The developing bar ticks, and a forced disconnect recovers cleanly | 2–5 days |
| 4 · Read-only trading | Real accounts and positions display; no order path exists yet | 2–5 days |
| 5 · Order entry | A paper order is accepted, filled, and reflected from broker state | 3–10 days |
| 6 · Production | Entitlements enforced, monitored, and someone owns the pager | 1–2 weeks |
Phase 4 before phase 5 is the important ordering. Displaying broker state proves your adapter, identity mapping, and event plumbing while every mistake is harmless. Adding order entry to a proven read path is a small change; adding it to an unproven one means debugging two things at once with money involved.
Start at Quickstart for phase 1 and Build a REST and WebSocket chart for phases 2 and 3.
Topology by team size
| Solo | 2–20 seats | Established desk | |
|---|---|---|---|
| Deployment | One host or one container | Managed containers, one region | Multi-tier, colocated session layer |
| Data source | Broker-supplied or one vendor | One vendor plus a bar store | Venue feeds plus vendors for reference data |
| Execution | Broker REST or WebSocket | Broker API | FIX with drop copy |
| Identity | Single user, local auth | Your existing SSO | SSO plus per-seat entitlement records |
| Storage | Browser local storage | REST chart storage adapter | Chart storage backend with audit retention |
| On call | The trader | Whoever built it | A rota |
The code does not change between columns. The gateway contract, the datafeed, and the broker adapter are the same objects; only what sits behind them moves.
Entitlements and licensing
This is the part that surprises desks, because it is commercial rather than technical and it constrains the architecture anyway.
- A chart is display use, priced separately from non-display use by most venues.
- Showing data to anyone who is not the licensee is redistribution and usually needs its own agreement. Your own desk and your clients are different licenses running identical code.
- Seats are counted per user, not per connection — which is why the gateway deduplicates upstream subscriptions rather than opening one per tab.
- Delayed or end-of-day data carries far lighter obligations. If the strategy does not need real time, establishing that early is the cheapest decision available.
- Broker API terms may restrict use to your own accounts. TradeZero's API, for example, is personal-use only.
Enforce entitlement at the gateway, per request and per subscription, and return a typed error rather than an empty result — so "you are not licensed for this" never looks like "this instrument has no data".
Identity and storage
Charts are per user. Chart layouts, drawings, watchlists, and settings are per user and usually per account. Wire your existing session — cookie or bearer token — into the gateway calls and the WebSocket upgrade, resolve it to a user there, and key storage on that identity.
Browser local storage is fine for phase 1 and wrong for production: it does not survive a device change and cannot be audited. Move to the REST chart storage adapter before go-live, and version records so a chart layout written by an older build still loads.
Operations
What pages someone, and what to watch:
| Signal | Why it matters |
|---|---|
| Upstream session state | A dead FIX session or a logged-out IBKR desktop session stops everything |
| Sequence gaps per subscription | Silent gaps corrupt books and volume |
| History request budget | Pacing limits are consumed by ordinary scrolling |
| Stream fan-out lag | A slow consumer must be disconnected, not allowed to stall the reader |
| Rejected orders by reason | A spike usually means a mapping bug, not a market condition |
| Entitlement denials | Distinguishes a licensing problem from a data outage |
Scheduled work belongs on the calendar before it surprises you: IBKR sessions need a weekly re-authentication and daily restarts; FIX sessions have contracted start and end times and sequence resets; vendor bulk history loads run nightly.
Go-live checklist
- Phases 1–5 each demonstrated, in order, with paper before live.
executionEnvironmentdeclared by the adapter; paper and live credentials stored separately.- Order rejections surface the broker's own message to the trader.
- Positions and executions come from broker or drop-copy state, never inferred client-side.
- Entitlements enforced at the gateway and typed errors distinguishable from empty results.
- History cached server-side; pacing and rate budgets centrally queued.
- Chart layouts and drawings on the chart storage backend, versioned.
- Disconnects visible in the UI rather than masked by stale state.
- A runtime smoke suite covering mount, data, interaction, and cleanup runs before each release.
- One named person owns the weekly re-authentication and the pager.
Next steps
- Backend integration overview — the reference architecture behind all of this.
- Build the data gateway — the service every phase after 2 depends on.
- Runtime integration testing — proving the mounted integration before release.