DEV Community

Matthieu David
Matthieu David

Posted on

Why I Built a No-Code Backtesting Engine (And What I Learned About Anti-Repainting)

I'm a trader and full-stack dev. I spent 5 years trading Forex, got funded on FTMO, lost it all when market conditions changed. The one thing that could have saved me? Proper backtesting before going live.

The problem is, backtesting tools suck for non-coders. TradingView requires Pine Script. MetaTrader requires MQL. QuantConnect requires Python/C#. If you're a visual trader using SMC/ICT concepts, you're stuck manually scrolling through charts bar by bar.

So I built Backtrex - a no-code backtesting platform where you drag visual blocks instead of writing code.

The anti-repainting problem nobody talks about

Here's something I discovered while building the backtesting engine: most indicators repaint and nobody warns you about it.

Repainting means an indicator changes its past values based on future data. Your backtest shows a perfect entry signal, but in live trading that signal never existed at that candle. Your backtest is lying to you.

Common offenders:

  • Zigzag indicators - they redraw when a new pivot forms
  • Renko charts - bar boundaries shift as new data arrives
  • Community Pine Script indicators - many use close (current bar) instead of close[1] (confirmed bar)

Our engine enforces a simple rule: every indicator only uses close[1] (the previous confirmed bar). Current bar data is never used in signal generation. This alone eliminates the most common source of false backtest results.

The architecture decision that saved us

We considered two approaches for the backtest engine:

  1. Event-driven (process each tick/bar sequentially)
  2. Vectorized (compute all signals at once using numpy arrays)

We went with event-driven despite being slower, because it accurately models what happens in live trading. You can't know the next bar's close when you're deciding to enter on the current bar. Vectorized backtests often introduce subtle lookahead bias.

The tradeoff: we had to optimize heavily to keep backtests under 30 seconds on 10 years of M1 data. Cython for hot paths, pre-computed indicator caches, and a custom candle aggregation pipeline.

What I'd do differently

  • Start with fewer indicators. We built 50+ blocks. 80% of users use the same 10. Ship the core fast, add the rest later.
  • Don't underestimate Pine Script export. Users want to deploy on TradingView after validating in our tool. The export parity guarantee (<2% divergence) took 3x longer than expected.
  • Build for the community you're in. Our best early users are SMC/ICT traders because nobody else builds native Order Block and FVG detection. Find your niche before going broad.

If you're interested, the landing page is at backtrex.com. Still in early access, feedback welcome.


Building in public. AMA in the comments.

Top comments (0)