Project specifications
- Market
- EURUSD / GBPUSD
- TF
- M5
- Platform
- MT4
- Client type
- Existing EA owner
- Delivery window
- 4 weeks
- Stack
- MQL4, order logs, M5 data for two pairs
- Strategy
- Execution price control
- Modules
- Slippage cap + smart retry
- Testing
- Busy-hour testing
Who this was for
Navid Pakzad
- Role
- Owner of a high-frequency expert
- City
- Isfahan
- Project reference
- TBT-1408-29
The client's idea
Navid Pakzad works EURUSD / GBPUSD on M5; the opening brief was: In busy hours my orders fill at bad prices — fix that.
Initial challenge
The expert sent orders with no slippage ceiling, and in busy hours they filled several pips worse.
Solution
A slippage ceiling, a spread check before sending, bounded retries on rejection, and full logging of the gap between requested and filled price.
Why this design
Retries are bounded so a fast market does not turn them into extra cost. It matches how EURUSD / GBPUSD 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.
- 0.5 pip Average execution slippage
- 4 Defects fixed
- 40 ms Order round-trip time
- 99.9 % Runtime stability in test
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 / GBPUSD.
Day 1–1
-
Written specification
CompletedA written list of approved changes — and of what stays untouched at this stage.
Day 2–5
-
Implementation
CompletedApplying small, reviewable changes instead of needlessly rewriting healthy parts.
Day 6–15
-
Testing and validation
CompletedRegression testing the old behaviour and targeted testing of what had to change.
Day 16–21
-
Handover and support
CompletedHandover of the fixed build with a change report and the reason behind each change.
Day 22–25