What We Do in the First Two Days of Your EA Project (It’s Not Writing Code)

A brief that says “medium complexity, standard EA” can hide twenty or more 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.

Some of them cause 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 appears 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.

Take a brief for a grid recovery EA. The strategy is coherent. The specification is detailed. It covers every aspect of normal operation and says 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 multi-year backtest, a dual-signal scenario like this can occur dozens of times. A brief leaves it out because the client has not thought about it, not out of carelessness: the client genuinely does not know the question needs 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

A strategy may need 0.01 lot granularity to meet its risk-per-trade targets while the broker’s minimum on that instrument is 0.10. That is rarely in the strategy specification. Requesting the broker’s symbol specification sheet in the first session catches the mismatch; catching it after the risk module is built means rebuilding the module 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:

“Two signals fire on the same bar — which one takes priority?”

The instinctive answer is “That can’t happen.” A multi-year backtest on the instrument settles it, and the EA gets a code-ready answer: for example, first signal wins, second is discarded, with a log entry recording the collision. Without that question, the behavior is 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?”

A network interruption during a stop-loss modification can leave a position in a stuck state — the modification neither confirmed nor rolled back. Resolving it requires a dedicated recovery routine in OnInit() (opens in a new tab) that checks for in-flight modification states at startup and closes or resets them as appropriate. A brief rarely specifies this, because few clients have thought about it.

“At what equity level does risk reduction kick in, and does it apply to existing open positions or only new ones?”

Ask three stakeholders on the same team and you can get three different answers — the question does not have an obvious answer until someone asks it. An hour of discussion turns it into a single unambiguous rule the EA can encode. Without that hour, the EA is built on one interpretation, tested against a second, and goes 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 an audit or rescue of an EA written by another developer — or generated by AI tools — finds no such document, the code typically handles the normal case correctly and collapses on first contact with anything outside it.

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.

An illustration of what the analysis changes, for two projects of the same complexity tier and similar strategy types:

The difference is not the quality of code written: both are written to the same standards. The difference is the completeness of the specification the code is 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, 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.