The brief said “medium complexity, standard EA.” The first requirements session surfaced 23 unresolved edge cases. Before writing a single line of MQL, a professional MT4 programmer spends 12–16 hours on requirements elicitation, edge-case mapping, and broker constraint modeling — this is the work that determines whether an EA survives production.
Three of those edge cases would have caused silent failures in live trading — orders rejected without errors, positions stuck open after reconnect, lot sizes calculated against a broker minimum the strategy spec never mentioned. None would have appeared in a backtest. This work is invisible to the client, not delivered as a document, and not replicable from a vague brief.
What Most Project Briefs Miss
Most project briefs describe the normal case well. Entry logic, exit logic, position sizing — it is all there. What is missing is the 20–30 edge conditions that determine whether the EA collapses the first time the market does something unexpected.
The brief above described a grid recovery EA. The strategy was coherent. The specification was detailed. It covered every aspect of normal operation and said nothing about what happens when a stop level violation silently rejects an order, when equity drops below margin while an open position is being modified, or when two signals fire on the same bar and both meet entry criteria.
These are not exotic conditions. In a 3-year backtest on the specified instrument, the dual-signal scenario occurred 67 times. The brief never mentioned it because the client had not thought about it. The brief was not incomplete — the client genuinely did not know the question needed asking.
That is what the first session is for.
Broker Constraint Mapping
A trading strategy specification describes what the EA should do. Broker specifications describe what the EA is actually allowed to do. Reconciling them before writing code takes 2–3 hours and prevents a class of runtime failures that do not appear in backtesting.
For every project, we validate:
- Minimum lot size — the floor on position sizing; determines the smallest increment the risk module can work with
- Maximum lot size — the ceiling that caps grid and recovery strategies at their natural scaling limit
- Stop level — the minimum distance in points from current price for stop and limit orders. Commonly misunderstood as zero on ECN brokers; when non-zero, stop-placement logic that passes every backtest silently rejects orders in live conditions
- Spread behavior during news — affects time filters and the viability of pending order placement around high-impact events
- Margin calculation mode — determines how the broker calculates equity and free margin during position scaling, which affects the risk module’s headroom estimates
One recent project required 0.01 lot granularity to meet the client’s risk-per-trade targets. Their ECN broker had a 0.10 minimum on the instrument in question. This was not in the strategy specification. The mismatch was caught in the first session by requesting the broker’s symbol specification sheet. Catching it after the risk module was built would have required rebuilding it from scratch.
Edge-Case Elicitation: The Questions Clients Can’t Answer Without Being Asked
Professional EA development is largely the work of converting implicit assumptions into explicit decisions. Most assumptions surface only when we ask the right question — the client cannot volunteer what they have not considered.
These are standard questions from our requirements process, with the answers that surprised clients:
“Two signals fire on the same bar — which one takes priority?”
Client response: “That can’t happen.” We pulled a 3-year backtest on the specified instrument. It happened 67 times. The EA now has a code-ready answer: first signal wins, second is discarded, with a log entry recording the collision. Without that question, the behavior would have been undefined — and undefined behavior in an EA means the platform decides for you.
“What happens if the terminal disconnects while a position modification is in-flight?”
Not in the brief. In forward testing, a network interruption during a stop-loss modification left a position in a stuck state — the modification was neither confirmed nor rolled back. Resolving this required a dedicated recovery routine in `OnInit()` that checks for in-flight modification states at startup and closes or resets them as appropriate. The client’s brief had no specification for this because they had never thought about it. It is one of the most common causes of unexplained EA behavior in live trading, and it is almost never in the brief.
“At what equity level does risk reduction kick in, and does it apply to existing open positions or only new ones?”
Three stakeholders on the same team gave three different answers. This is not unusual — the question does not have an obvious answer until someone asks it. An hour of discussion resolved it into a single unambiguous rule that the EA could encode. Without that hour, the EA would have been built on one interpretation, tested against a second, and gone live against a third.
Each of these produces a concrete, agreed-upon decision that exists in writing before the code editor opens.
The Edge-Case Map: Turning Ambiguities Into Code-Ready Decisions
Every unresolved ambiguity becomes either a production failure or a debugging session billed at emergency rates after something has already gone wrong in a live account.
We resolve them before writing code, in writing, so there is no ambiguity later about what was agreed.
The artifact this produces is an internal edge-case map: a structured list of every identified condition, the agreed handling decision, and the conditional branch in the EA logic it maps to. It is not a client deliverable — the client never sees it. Internally, it functions as the conditional logic specification: the document that answers every “what should happen when X” question before that question can become a runtime failure.
When we are engaged to audit or rescue EAs written by other developers — or generated by AI tools — the absence of this document is nearly universal. The code handles the normal case correctly. It collapses on first contact with anything outside that case.
That is not a code quality problem. It is a requirements problem. The code does exactly what it was told to do. What it was told to do was incomplete.
What 12–16 Hours of Analysis Actually Prevents
The upfront analysis takes 12–16 hours on a moderately complex EA. It is not optional overhead — it is the work that makes the code work.
Two comparable projects from the same quarter, same complexity tier, similar strategy types:
| With upfront discovery | Without upfront discovery | |
|---|---|---|
| Revision rounds in testing | 1 | 3 |
| Additional hours beyond original estimate | 0 | 34 |
| Delivery vs. schedule | On time | 3 weeks late |
| Post-delivery support requests (first 60 days) | 0 | 4 |
The difference was not the quality of code written. Both were written to the same standards. The difference was the completeness of the specification the code was written from.
This analysis — requirements elicitation, broker constraint mapping, edge-case resolution — is what the first phase of a barmenteros FX Custom EA Development engagement covers. Clients who want to skip it are not saving money. They are deferring the same work to a later phase where it costs more: debugging rates, in a live account, after something has already failed.
If your project is at the planning stage, request a free consultation — describe the strategy and the intended broker, and we will map the edge cases before the build starts. If you want to prepare the brief yourself first, this specification guide covers the questions worth answering before the first session.
The brief that looks complete rarely is. The first two days are how we find out.
Leave a Reply