Every EA project starts with a brief. The brief describes entry conditions, exit logic, position sizing, and timeframe. It is usually thorough on paper. In practice, it is almost never complete.
The underlying problem: EAs fail in live trading not because of code quality, but because of incomplete requirements. The brief covers the normal case. The code is built for the normal case. The live market does something outside the normal case — and the EA has no handling rule because nobody wrote one.
The work we do in the first two days of a project addresses this gap before it becomes expensive.
Requirements Elicitation: The Questions That Define the Edge Cases
The first session is not a coding session. It is a structured question-and-answer that surfaces conditional decisions the brief doesn't cover.
Three questions from our standard requirements checklist that expose the most expensive gaps:
What happens if two signals fire on the same bar? This scenario typically doesn't appear in strategy descriptions because traders reason in terms of normal market flow. The instinctive answer is "that can't happen." A multi-year backtest on the instrument settles it. Resolution, for example: first signal wins, second is discarded, with a log entry recording the collision. Without that session, the EA applies an arbitrary default — whichever branch the code encounters first.
What should happen if the terminal disconnects during an order modification? A network interruption during a stop-loss modification can leave a position in a stuck state — the modification is neither confirmed nor rolled back. This requires a recovery routine in `OnInit()` that checks for discrepancy between stored state and current position state:
int OnInit() { // Check for in-flight modification states from previous session for(int i = OrdersTotal() - 1; i >= 0; i--) { if(!OrderSelect(i, SELECT_BY_POS, MODE_TRADES)) continue; if(OrderMagicNumber() != MAGIC_NUMBER) continue; double storedSL = ReadStoredSL(OrderTicket()); // From persistent state if(storedSL > 0 && MathAbs(OrderStopLoss() - storedSL) > Point * 5) { printf("%s: Stuck modification detected | Ticket=%d | CurrentSL=%.5f | StoredSL=%.5f", __FUNCTION__, OrderTicket(), OrderStopLoss(), storedSL); SetModificationPending(OrderTicket(), storedSL); // Re-queue for next tick } } return INIT_SUCCEEDED; }
Without this recovery check, the position stays stuck until manual intervention. A brief describes the strategy. It rarely describes what recovery from a disconnected modification looks like — because few clients have considered the scenario.
At what equity level does risk reduction activate, and does it apply to new positions or existing ones? Ask different stakeholders this question and you can get different answers. The EA gets built on one interpretation. Asked properly, the question can reveal that the intended behavior is a third answer that neither group has articulated.
Each of these questions resolves into a code-ready decision before a function is written.
Broker Constraint Mapping: 5 Parameters Before the Risk Module
After the strategy brief, we validate broker constraints. These five parameters affect the EA's behavior regardless of what the strategy spec says:
- Minimum lot size (`SYMBOL_VOLUME_MIN`) — the floor on position sizing. A strategy with 0.01 granularity cannot execute on a broker where the instrument minimum is 0.10.
- Maximum lot size (`SYMBOL_VOLUME_MAX`) — the ceiling, relevant for grid and recovery strategies.
- Stop level (`SYMBOL_TRADE_STOPS_LEVEL`) — the minimum distance in points between the current price and a stop-loss or take-profit. On ECN brokers, this is frequently reported as zero in documentation but is non-zero in practice. Stop placement logic that passes every backtest silently rejects orders in live conditions when this is not accounted for.
- Spread behavior during news — affects time filter logic and pending order placement windows.
- Margin calculation mode — determines how equity and free margin are calculated when positions are open, which affects grid and compound-position sizing.
A strategy may need 0.01 lot granularity while the broker's minimum on the specified instrument is 0.10. Requesting the symbol specification sheet in session one catches that mismatch before the risk module is built. Discovering it after the module is complete means rebuilding the position sizing logic from scratch.
The Edge-Case Map
The artifact produced by this phase is an internal document: a structured list of every identified edge condition, the agreed handling decision, and the conditional branch it maps to. It is not a deliverable to the client. It functions as the conditional logic specification for the developer.
When an audit of an EA built by another developer — or generated by AI code tools — finds no such document, the code typically handles the normal case correctly and fails on first contact with anything outside it. That is not a code quality problem. It is a requirements problem.
The Numbers
An illustration of what the analysis changes, for two projects of the same complexity tier:
| With upfront discovery | Without | |
|---|---|---|
| Revision rounds | 1 | 3 |
| Extra hours billed | 0 | 34 |
| Delivery | On time | 3 weeks late |
| Post-delivery support requests | 0 | 4 |
The code quality is the same. The specification quality is not.
Twelve to sixteen hours of upfront analysis is not overhead. It is the work that makes the code work in production — because production will encounter every scenario the brief didn't mention.
