You have a trading strategy that works manually. You want it automated. You find a developer, describe what you want, and wait. Two weeks later, you get an EA that does something completely different from what you envisioned. The difference between an EA project that costs $500 and one that costs $2,000 for the same strategy is almost always the specification — vague briefs create expensive revision cycles, while precise walk-through scenarios with specific values cut development time and eliminate misunderstandings. This happens in roughly half of all first-time EA commissions I see, and it is almost never the developer’s fault.
This is a process reveal — what a good EA specification looks like, what a bad one looks like, and the single most useful thing you can provide to any developer before a line of code is written.
The $1,500 Misunderstanding
Most EA project cost overruns come from revision cycles, not from complex strategy logic. A vague brief forces the developer to guess — and guessing wrong costs both parties time and money.
Here is a real pattern I see regularly. A client writes: “Entry when price crosses the level.” The developer builds crossover detection — price was below the level on the previous tick, now it is above it. The client meant something different: “When price touches the level for the first time.” Those are two different behaviors. Crossover requires the price to be on the opposite side first. A first-touch entry fires the moment price reaches the level from any direction.
That four-word ambiguity — “crosses” versus “touches” — took three revision rounds to resolve. Each round cost days of back-and-forth. The developer was not wrong. The specification was.
In 14+ years of building EAs, I have found that the specification quality predicts project cost more reliably than strategy complexity. A complex strategy with a clear specification is straightforward to build. A simple strategy with a vague specification becomes a guessing game.
What a Bad Specification Looks Like
Bad specifications share three patterns: missing edge cases, ambiguous trigger language, and unstated assumptions about execution behavior. Here are three real examples from client projects, anonymized:
“Use a martingale system.” That is the entire specification. No lot progression formula. No maximum drawdown limit. No stop condition. Does the lot double after every loss? Triple? Does it reset after a win or after reaching a target? What happens when the margin runs out — does the EA stop, or does it skip a level and wait? Every one of these questions changes the code architecture. Every unanswered question becomes a revision cycle.
“Close all trades when profit reaches target.” Target per-trade or per-basket? Floating profit or realized profit? If the EA has five positions open and the combined floating profit reaches $100, does it close all five? Or does it close each position individually when that position reaches $100? These two implementations have completely different code paths, different exit behaviors, and different P&L outcomes.
“Same as my other EA but for gold.” This assumes gold and forex pairs behave identically inside MetaTrader. They do not. Gold uses a different tick size, wider spreads, higher margin requirements, and different lot step values. An EA that calculates position size correctly on EURUSD will calculate it wrong on XAUUSD unless the sizing formula accounts for `SYMBOL_TRADE_TICK_SIZE` and `SYMBOL_TRADE_TICK_VALUE` — values that differ per instrument. “Same but for gold” is not a small change. It often requires reworking the entire risk management module.
The Walk-Through Scenario — The Single Most Valuable Thing You Can Provide
A step-by-step scenario with specific prices and values eliminates more ambiguity than 10 pages of general description. It forces you to think through your strategy concretely and exposes assumptions you did not realize you were making.
Here is an example of a clear walk-through:
Price is at 1.10500. My indicator gives a buy signal. The EA opens a buy at market with 0.10 lots. Stop loss at 1.10200 (30 pips below entry). Take profit at 1.11100 (60 pips above entry). If price moves to 1.10800 (30 pips in profit), move the stop loss to 1.10500 (breakeven). After that, trail the stop loss 20 pips behind price for every new 10-pip move upward.
Now compare that with: “EA should trail the stop loss.”
The first version can be coded in hours. The developer knows the exact activation point, the exact trail distance, and the exact step interval. The second version starts a clarification thread that adds days to the project.
The walk-through scenario approach also catches edge cases early. When you write it out step by step, you naturally hit questions like: “What if the price gaps past my stop loss on a Monday open?” or “What if the indicator gives a buy signal while I already have an open buy?” If you catch those in the specification, the developer handles them on the first pass. If you do not, they surface as bugs in testing — bugs that require revision cycles to fix.
The Specification Checklist — Seven Questions That Prevent Scope Explosions
Over 14 years and hundreds of EA projects, I have found that seven questions, answered upfront, cover roughly 90% of the ambiguities that cause revision cycles. If you answer these before your first message to any developer, you will get a faster quote and a more accurate first delivery.
| # | Question | Why It Matters |
|---|---|---|
| 1 | Entry conditions — what is the exact trigger? Provide a walk-through scenario with specific prices. | “When RSI crosses 30” needs: crosses from below? Closes below? On which timeframe? On the current bar or after bar closes? |
| 2 | Exit conditions — stop loss, take profit, trailing, time-based, signal-based? All of them? | Missing even one exit path means the EA can hold positions indefinitely — or close them unexpectedly. |
| 3 | Position sizing — fixed lot, risk-based percentage, or scaling? Provide the formula with a specific numerical example. | “Risk 2% per trade” is not enough. 2% of balance or equity? What is the stop loss distance in that calculation? |
| 4 | Multiple positions — can the EA have more than one position open at a time? What is the limit? | An EA that allows unlimited positions has a fundamentally different architecture than one limited to a single position per symbol. |
| 5 | Symbol scope — which symbols will it trade, and does it need to behave differently on each? | Lot step, tick size, margin requirements, and spread behavior all vary per instrument. “All forex pairs” is not a simple request. |
| 6 | Timeframe dependencies — which chart timeframe does the logic use? Does it reference multiple timeframes? | Multi-timeframe EAs require explicit data handling for each timeframe — this is not automatic in MetaTrader. |
| 7 | Error recovery — what should the EA do when an order fails? Retry? Alert? Stop trading? | Brokers reject orders for dozens of reasons. The EA needs explicit behavior for each failure mode, not just a log message. |
You do not need to be technical to answer these questions. Write in plain language. Use specific numbers. The walk-through format works for every one of them.
What Happens When Your EA Specification Is Clear
Projects with walk-through scenarios average zero to one revision rounds in my experience. Projects with vague specifications average three to four rounds. At typical developer rates of $50–100 per hour, that gap represents $500 to $1,500 in unnecessary cost for the exact same end product.
The specification does more than save money. It becomes the reference document for the entire project. When a question comes up during development — “should the EA re-enter after hitting stop loss?” — both parties point to the specification. No ambiguity, no conflicting memories of a chat conversation from two weeks ago.
At barmenteros FX, when we receive a specification with walk-through scenarios, the first delivery typically matches the client’s expectations. The specification did the heavy lifting before any code was written. The developer’s job shifts from interpreting vague intent to implementing precise behavior — and that is a much cheaper job.
Thirty minutes writing a clear specification saves weeks of back-and-forth and hundreds of dollars in revision costs. That is the highest-return preparation you can do before commissioning any EA project.
If you are preparing to commission an EA and want to make sure your specification covers everything, send us your brief — we will review it and let you know if anything is missing before quoting.
Leave a Reply