Project specifications
- Market
- EURUSD
- TF
- M5
- Platform
- MT4
- Client type
- Existing EA owner
- Delivery window
- 6 weeks
- Stack
- MQL4, the client's existing code, data from strong trends
- Strategy
- Basket guard on an existing grid
- Modules
- Drawdown cap + basket close
- Testing
- One-way market scenario test
Who this was for
Hossein Azarnia
- Role
- Owner of a legacy grid expert
- City
- Tabriz
- Project reference
- TBT-1402-06
The client's idea
Hossein Azarnia works EURUSD on M5; the opening brief was: Do not touch the grid logic — just stop a one-way market from wiping the account.
Initial challenge
The grid expert had worked well in ranging markets for years, but a three-month trend had taken a large part of the account.
Solution
A guard layer added without touching the grid: daily equity stop, a hard cap on open positions, and basket liquidation under critical conditions.
Why this design
The original code was preserved so the behaviour stays familiar, with the change confined to an outer layer. It matches how EURUSD is actually traded and can be tested against the data already available.
Safeguards and risk control
Every change starts from a saved backup, and the previous behaviour is kept as the test reference.
Our next-step proposal
The next step is a full technical review of the expert and clearing the old code's debts.
Portfolio
Measured results
These are the figures the test produced — not a promise about future performance.
- 7 Defects fixed
- 6 Concurrent position cap
- 13.5 % Max drawdown in test
- 5 days Recovery after drawdown
Portfolio
How the delivery ran
Every project moves through these five phases, with the window for each agreed in the specification.
-
Discovery and problem framing
CompletedAuditing the existing code, finding the cause of the fault and fixing the change scope on EURUSD.
Day 1–3
-
Written specification
CompletedA written list of approved changes — and of what stays untouched at this stage.
Day 4–10
-
Implementation
CompletedApplying small, reviewable changes instead of needlessly rewriting healthy parts.
Day 11–26
-
Testing and validation
CompletedRegression testing the old behaviour and targeted testing of what had to change.
Day 27–35
-
Handover and support
CompletedHandover of the fixed build with a change report and the reason behind each change.
Day 36–39