Each project arrives with its purpose, milestones and first tasks written out. Here is how the first three read.
What the paper trial has to prove
A paper trial without a stated question drifts into watching numbers and hoping. Writing down, in three or four lines, what the trial must show (signals match the backtest, fills are achievable, the code survives real sessions, you follow the rules) turns it into a test you can pass or fail rather than a waiting room before going live.
First tasks
- Write the strategy, market and timeframe at the top of a new trial brief
- List the three or four questions the trial must answer
- Pair each question with the evidence that would settle it
- Note what paper trading cannot show, such as your own market impact
Choosing a paper trading venue and simulator
Broker paper accounts, exchange testnets and your own simulator fed by live quotes all fill orders differently, and some fill at prices you could never get. Picking the venue on purpose, against the order types and data your strategy actually needs, decides how believable every later result will be.
First tasks
- List the order types and data frequency the strategy needs
- Shortlist two or three paper venues that support them
- Read each venue's documentation on how simulated orders are filled
- Place and cancel a test order on the chosen venue
Frozen strategy version for the trial
Tweaking parameters during a paper trial quietly resets it, because the results no longer belong to the version you backtested. Tagging one exact version of code, parameters and configuration as the trial build, and changing it only through a logged restart, keeps the comparison with the backtest honest.
First tasks
- Commit the strategy code, parameters and config together
- Tag the commit as the paper trial version
- Make the strategy log its version number on every start
- Write the restart-on-change rule into the trial brief
