Backtesting Is Easy. Execution Is the Hard Part.

[brokermr810]

I’ve spent a lot of time working with research-heavy tools — vectorized backtesting, parameter sweeps, notebooks full of results.

They’re incredibly powerful.

But at some point, I started noticing a pattern:
the better my research tooling became, the more painful the transition to execution felt.

Not because the strategy was bad —
but because nothing in the research environment prepared me for what comes next.

Research Environments Are Designed to Be Ideal

Vectorized backtesting frameworks do exactly what they’re supposed to do:

fast experimentation

clean abstractions

reproducible results

deterministic behavior

You change a parameter, rerun the notebook, compare outcomes.
Everything is inspectable, rewindable, and explainable.

That’s a feature — not a flaw.

But it also creates a false sense of completeness.

The Moment Research Ends

The real difficulty begins the moment you ask:

“How does this actually run, continuously, in real time?”

That question immediately breaks most research assumptions.

Suddenly, you’re dealing with:

asynchronous data instead of aligned arrays

state that persists across hours or days

partial fills instead of perfect execution

restarts, retries, and edge cases

behavior that can’t be replayed with a single function call

None of this fits naturally into a notebook cell.

The Debugging Problem No One Prepares You For

In research, if something looks wrong, you rerun the code.

In live systems, you don’t get that luxury.

At some point, everyone hits the same wall:

“Why did the system place this trade?”

Answering that requires more than a strategy function.

It requires:

explicit state tracking

clear separation between signal and execution

logs that reflect decisions, not just outputs

a system designed to be inspected after the fact

If execution logic is treated as an afterthought, this question becomes impossible to answer confidently.

Execution Is a System, Not a Wrapper

A common mistake is to think of execution as a thin wrapper around research logic.

In practice, execution behaves like a separate system with its own rules:

it has memory

it has failure modes

it has timing constraints

it has irreversible actions

You can have a well-researched strategy and still end up with a fragile system if execution isn’t designed deliberately.

Why This Gap Matters

Most optimization effort goes into research:

parameter tuning

indicator selection

portfolio construction

Much less effort goes into asking:

What happens if data arrives late?

What happens if the process restarts mid-position?

Can I reconstruct system state from logs alone?

Do I know why a trade happened, not just that it happened?

In my experience, these questions matter more than squeezing a few extra basis points out of a backtest.

A Personal Shift in Perspective

At some point, I stopped asking:

“How can I improve this backtest?”

And started asking:

“What kind of system would I trust to run unattended?”

That shift changed how I approached everything:

architecture before indicators

observability before optimization

execution clarity before strategy complexity

Research tools are still essential — but they’re only one part of the picture.

Closing Thought

Backtesting explores ideas.
Execution tests assumptions.

The harder part isn’t finding signals —
it’s building systems that behave predictably when nothing goes as planned.

I’m curious how others here think about bridging this gap between research environments and long-running execution systems.