MQL5 / Algo Trading Developer Systematic MT5 Intraday System

I'm looking for an experienced developer to build a modular, fully automated intraday system for MetaTrader 5 — specifically someone who can test a trading idea properly and tell me when it doesn't hold up, before it costs money live.

To be clear up front: I'm paying for an honest answer, not for a "yes". If an idea fails in testing, that's a valid deliverable and gets paid in full.

The project

A modular intraday system for MT5.

We start with one strategy module that can be validated properly. Modules 2 and 3 come afterwards. The reason: developing three strategies in parallel usually means none of them gets tested thoroughly. The architecture is built from day one so additional modules can plug in cleanly later.

Ground rules:

• No overnight exposure
• No martingale, reverse martingale, grid, or averaging down
• No news-spike trading; high-impact windows get filtered, not traded
• Risk determines lot size, never the other way around. Max. ~1 % per trade as total system risk, not per module
• A global risk layer across all modules: total exposure, daily loss limit, equity drawdown stop, max concurrent positions

What matters more to me than any feature list

Before we write code, I'd like to work through three questions with you:

1. What market inefficiency are we exploiting?
2. Who is on the other side of the trade, and why are they losing money there?
3. Why should this effect still exist twelve months from now?

"Momentum breakout with a volatility filter" describes indicators, but it doesn't answer these questions. Without a plausible answer, what we end up with is a good-looking backtest without substance — and that's exactly what I want to avoid.

If you see this differently and think another approach makes more sense, please say so. Pushback is genuinely welcome.

Paid, phased process

Phase 0 — Research sprint (fixed price, approx. 2–3 weeks) We pick 1–2 hypotheses together. You build a rough prototype — the code can be ugly at this stage — and give me an assessment: does the idea hold up, and where does it break? A "this doesn't work" result is paid in full, regardless of outcome.

Phase 1 — Implementation Production-grade, modular code: strategy module, global risk layer, position sizing, filters, trade logging.

Phase 2 — Validation Out-of-sample, walk-forward, Monte Carlo, parameter stability.

Phase 3 — Forward test 8–12 weeks on demo or small live under real broker conditions. Final sign-off happens here, not at code handover — the forward test is the only test that can't be optimized in hindsight.

Phase 4 (optional) — Modules 2 and 3 If module 1 delivers in phase 3 what the backtest promised.

Acceptance criteria

I want measurable criteria instead of vague wording like "controlled drawdown" — but I'm deliberately not fixing the numbers upfront. Meaningful thresholds only emerge from phase 0, once we know what the strategy realistically produces. Numbers I invent beforehand just get optimized against.

After phase 0 we agree on and document:

• Minimum number of trades in the validation period (statistical significance)
• Minimum profit factor and expectancy
• Maximum equity drawdown
• Acceptable degradation from in-sample to out-of-sample
• Parameter stability: how much deviation on the core parameters must remain profitable
• The range the forward test has to stay within (trades/day, avg. R, DD)

A system that only clears the thresholds with one exact parameter set has not passed, as far as I'm concerned.

Handling overfitting

This matters more to me than any return target:

• I won't name the validation period upfront. You optimize on a defined window; the independent check runs on a period I choose. I'm aware historical data is freely available — which is exactly why the real independent test is the forward test in phase 3.
• Please document how many variants and optimization runs you tested. Not as a control mechanism, but because it changes the interpretation: 500 combinations with one winner is statistically very different from 5.
• Every parameter needs a short rationale for why it exists and why its range makes sense. Parameters without market logic get cut.
• Filters found after the fact to clean up the backtest are overfitting with extra steps. A filter should be justifiable beforehand.

Realistic testing

• Tick data, real spreads from my broker, commission, swap, conservative slippage assumptions
• Execution sensitivity analysis, already in phase 0: if the strategy breaks with +0.3 pips of additional slippage or noticeably higher latency, I want to know early. In short-timeframe trading, execution often matters more than the logic.
• Test broker and symbol dependency explicitly. Not every system needs to run on every symbol — candidates: EURUSD, GBPUSD, XAUUSD, NAS100, GER40, selection driven by data.
• Monte Carlo across trade order and trade omission: worst-case drawdown and longest losing streak, so I know what I'd have to sit through live.

Deliverables

• Source code (.mq5), commented, modular, modules cleanly separated
• Short architecture doc: how strategy modules, risk layer, and filters interact
• Parameter rationale
• Test reports: IS, OOS, walk-forward, Monte Carlo, parameter heatmaps
• CSV trade log per trade: strategy ID, magic number, symbol, direction, entry/exit, SL/TP, lot size, risk %, P/L, R-multiple, timestamps, holding time, spread at entry, market conditions
• Breakdown by month, weekday, time of day, session, long/short, symbol, module, market regime
• IP rights with the client, no resale of the system, NDA

How to apply

Five points are enough — short and specific:

1. Two or three systems you've built: instrument, logic in three sentences, how long it ran live, what happened afterwards.
2. One system that didn't work live — and your read on why. This one matters most to me; experienced developers usually have a case like this.
3. How do you handle overfitting in practice? Process and tools.
4. Your take on this brief: what do you consider unrealistic, or solvable a different way?
5. Price for phase 0, rough range for phases 1–3, weekly availability.

Templated applications and backtest screenshots with very high win rates don't tell me much — I'm more interested in how you think than in the result screenshot.

Budget range: 1000+ for phases 0–3. Phase 0 is paid separately and regardless of outcome. Optional, depending on fit: [performance component / revenue share — add if desired] if you'd also like to contribute on the research side.

What I'm after is robustness and risk-adjusted performance, not a headline percentage. A moderate, stable curve with controlled drawdown is far more interesting to me than high returns with high risk.

Looking forward to hearing from you — including critical questions about the concept.