GUI application built on top of Backtesting.py

[m-nf]

Hello,

I would like to ask for your opinion regarding a potential contribution related to Backtesting.py.

As part of my master’s thesis, I developed an early prototype of a GUI application that uses Backtesting.py as its backtesting engine (without modifying its core).

The GUI allows users to:

• download historical data and store it in Parquet format,
• configure parameters and execute backtests,
• store backtest results in a relational database,
• filter and compare backtest results,
• display multiple Backtesting.py result plots.

The application is written entirely in Python and uses a client-server architecture. Backtesting.py remains the computational engine, while the application provides orchestration, persistence, and a graphical interface layer on top.

The project is still in a prototype stage and would require further work to become robust enough for practical use. Before investing more time into development, I would like to ask whether you see any value in this kind of application within the Backtesting.py ecosystem.

Thank you for your time and for maintaining Backtesting.py.


Example screenshot of the prototype:

[rmbell09-lang]

This is a strong concept — the gap between I ran a backtest and I understand which of my strategies is actually best is real.

A few thoughts:

1. Strategy comparison is genuinely underserved. Most people end up with a folder of notebooks and no systematic way to compare them. Your filter and compare backtest results feature alone would save a lot of time.

2. Related project for validation: I built TradeSight which takes a complementary approach — instead of historical backtesting, it runs multiple strategies simultaneously in paper trading tournaments via Alpaca's free paper API. Different framing (live paper vs. historical), but the same core insight: you need side-by-side comparison to know which strategy is actually working.

3. The client-server architecture is smart. Backtesting.py is compute-intensive; keeping it as the engine while separating the UI layer makes it composable with other tools.

Whether or not it becomes a formal contribution to this repo, it sounds like a project worth finishing. The "orchestration + persistence + comparison" layer is exactly what's missing from most backtesting workflows.

[Panabou]

1. Strategy comparison is genuinely underserved. Most people end up with a folder of notebooks and no systematic way to compare them.

Right, in fact, comparing strategies based solely on returns is only an important first step; the real challenge lies in identifying a portfolio of different strategies that, when combined, produce a return curve that is as smooth (balanced) as possible.

[Panabou]

A GUI like that would lower the barrier to entry for backtesting and would therefore be very welcome!