“Remove the repainting from my indicator.” One line — so the client expected a day of work at minimal cost. That expectation is the costliest misunderstanding we see in custom MetaTrader development: a one-line request prices the idea, not the build — and this particular request, as written, could not be built at all: the accuracy the client wanted to keep on past bars was the repainting.
After 13+ years of MQL4/MQL5 client work at barmenteros FX, we see every “simple” request hide one of two things: a set of decisions nobody has stated yet, or — worse — a contradiction that makes the simple version impossible. The difference matters more here than in ordinary software, because the finished program operates real capital.
Why a “Simple” MT4 Application Feels Like a One-Day Job
Most requests for simple MT4 application development share the same shape: one sentence describing the outcome, an expectation of a day’s turnaround, and a budget anchored to that expectation. The logic feels reasonable — if the idea fits in one sentence, how big can the work be?
But the length of a request measures how clearly you can state the idea, not how much engineering the idea contains. It says nothing about what decides whether the work takes an afternoon or three weeks: broker behavior, platform constraints, restart behavior, failure handling. And unlike a website widget, a MetaTrader tool that guesses wrong doesn’t render badly — it trades badly, with your money.
The most expensive requests we handle are not the big ones. They are the small ones that were priced as small and then met reality. Two recurring requests show both ways that happens.
The Request That Contradicts Itself: “Remove the Repainting”
A repainting indicator revises its own past. It evaluates the candle that is still forming, draws a signal, and then — if the candle closes differently — moves or deletes that signal. Scroll back through history and you see only the survivors: clean arrows before every major move. That is the “accuracy” on past bars.
Now read the request again: remove the repainting, but keep the accuracy the indicator shows on history. Those are the same property. The impressive historical signals exist precisely because the indicator was allowed to revise them after the fact.
A non-repainting version has to commit: it evaluates only closed candles and never touches a printed signal again. That means signals arrive later, some disappear entirely, and the historical chart looks ordinary — because it now shows what you would actually have gotten live.
So the honest deliverable is not a patch. It is a behavior change the client has to accept before any code is written: which conditions count as a signal, evaluated at what moment, and whether they are prepared to see a truthful chart instead of a flattering one. In most of these projects, that conversation — not the programming — is the real work.
The Request That Looks Cosmetic: “Just Add a Panel”
The second archetype sounds even smaller: “add a panel to my EA” — buttons to switch modes, colors for status, a few display patterns. It reads like a paint job on a custom expert advisor that already works.
MQL4 and MQL5 give you no real user-interface framework. The closest thing — the Standard Library’s panel and button classes — is a thin wrapper over chart objects. Every button is still an object the program must create, position, redraw, and respond to through `OnChartEvent()`. A panel is not a styling layer — it is a second program grafted onto the trading program, with its own state to manage:
- What happens when the user switches timeframe and the chart rebuilds — does the panel remember its mode?
- What happens after a terminal restart in the middle of an open trade?
- What happens when a button is clicked while the EA is in the middle of sending an order?
Every additional button, toggle, and color multiplies the states that have to be handled and tested. That testing is not optional polish: an untested button on a funded account is a defect with a live position attached.
This is why an honestly quoted panel looks expensive next to the “it’s just visual” expectation. The request was priced as decoration; the build is structural.
The Decisions Hiding in Every Small Brief
Even a request with no contradiction still carries decisions the sentence never states. Every request below comes up again and again in our MT4 custom programming work — and each looks complete until you list what it quietly contains:
| The one-line request | What it quietly contains |
|---|---|
| “Close all my trades at 5pm” | Whose 5pm — server time or yours, and what about DST shifts? All trades, or only this EA’s? Partial closes on illiquid symbols? What if the terminal is offline at 5pm? |
| “Add a trailing stop” | Every tick or closed bars? The broker’s minimum stop distance clamps what you send. Does the trail survive a restart? How does it interact with the EA’s existing stop logic? |
| “Make the lot size 1% risk” | Pip value differs per symbol. Broker minimum, step, and maximum lot limits. Where does the stop distance come from? Enough margin before the order is sent? |
| “Push alert when price crosses a level” | Alert once per event, or on every tick that crosses? MetaQuotes ID setup on the phone. A terminal must be running somewhere 24/5. Duplicate alerts after a restart. |
| “Add a news filter” | MT4 has no built-in economic calendar — an external feed is required. Which events and impact levels count? Feed time zone vs. broker time. What does the EA do when the feed is down? |
Every one of those decisions gets answered — deliberately, because someone asked, or accidentally, because the programmer guessed. On a demo chart, an accidental answer is a quirk. On a funded account, it is a live defect.
How to Request a Tool So the Quote Matches Reality
The clarifying questions are the service. A developer who quotes your one-line request instantly, without a single question, has not seen something you haven’t — they have priced the guesswork into your account.
You can make the process faster from your side: bring the intent, not just the mechanism. “I want to be flat before the New York close because I can’t watch the market after that” tells a developer far more than “close everything at 5pm” — it answers half of the hidden decisions before they are asked.
When we scope this kind of work at barmenteros FX, the first deliverable is that list of decisions on paper, not code. How to write an EA specification that saves you money shows what that looks like as a document, and what MT4 programmers do before writing a line of code shows why the first days of a project produce no code at all.
So before sending your next “simple” request, re-read it once and classify it. Does it hide a decision set? Bring the answers. Does it hide a contradiction? Then expect a redesign conversation, not a quick fix. Either way, the questions that come back are not friction. They are the difference between a tool priced on the idea and a tool built for real money.
If you are sitting on a “simple” request right now and want to know what it actually contains before you commit a budget, send us the one-line version — we will send back the questions it raises before we send a quote.
Leave a Reply