A trading bot project starts with a specification that another person can test. “Automate my strategy” leaves important questions unanswered: when does a signal become valid, what happens after a rejected order, and what should the software do after restarting?
Use this engineering checklist when commissioning a new bot, an MT4/MT5 Expert Advisor, a custom indicator or a repair. It concerns software behaviour and verification. It is not a strategy recommendation or financial advice; testing cannot establish a promise of future returns.
1. Name the platform and operating conditions
Identify the exact platform, broker or exchange, instruments and account mode the software needs to support. Record relevant restrictions and the intended test environment. A platform name alone is not a complete execution specification.
Include:
- Supported symbols and their naming conventions
- Timeframes, trading hours and the reference time zone
- Position and order types the implementation must handle
- Required market data and indicator inputs
- Whether the bot operates alongside manual trades or other software
For a repair, add reproducible steps, the expected result and redacted logs. Keep passwords, API secrets and account credentials out of the initial brief.
2. Turn every strategy rule into an example
Describe entry and exit conditions precisely. Does the signal use the current candle or a closed candle? Can it fire once per bar, once per position or repeatedly? What happens if entry and exit conditions become true together?
Provide examples for both allowed and blocked actions. Specify position-sizing calculations, stop and target behaviour, order expiry and any exposure limits you have chosen. The developer needs to implement those decisions consistently rather than infer them from a chart.
Acceptance cases should name the input, expected decision and expected order behaviour. Include boundary values, missing data and conflicting signals.
3. Treat order submission and execution separately
A request being accepted does not necessarily establish that the intended trade has completed. In MQL5, OrderSend returning true does not by itself prove execution; the official reference directs developers to inspect result codes and track trade transactions. Read the MQL5 OrderSend reference.
Ask how the software represents submitted, rejected, cancelled and completed orders. Where applicable, specify partial fills and how the bot reconciles its internal state with the platform’s actual orders and positions.
A timeout needs an explicit recovery rule. Blindly resending a request can conflict with the original request if its outcome is still unknown. Define the evidence required before retrying.
4. Agree what backtesting will establish
Record the data source, date range, inputs, costs and execution assumptions for each test. Keep the software version with the results so that a later change can be compared on the same basis.
MetaTrader 5’s Strategy Tester offers different modelling settings and execution-delay simulation. Select settings deliberately and include them in the report. Read MetaTrader’s strategy-testing documentation.
Use historical tests to inspect whether the implementation follows the specified rules under the selected assumptions. Keep data reserved from parameter tuning when evaluating changes. A convincing chart is insufficient evidence that order handling, restart behaviour or controls work as intended.
5. Test operational failure cases
Agree a demo or non-production test plan covering:
- Rejected orders and unavailable trading sessions
- Missing or stale data
- Lost connections and reconnection
- Restarting with existing orders or positions
- Repeated signals and duplicate-action prevention
- User-defined limits, pause controls and manual intervention
- Logs that explain decisions without exposing credentials
Define the expected state after each failure. Decide whether the system should stop, alert someone, wait or attempt a bounded recovery. Make the person responsible for investigating exceptions explicit.
6. Specify handover and acceptance
Agree source-code deliverables, configuration instructions, test reports and the supported environment. Clarify monitoring, maintenance and what happens when a broker, exchange or platform changes its interface.
For each acceptance case, record a pass, a failure or an unresolved limitation. Separate an implementation defect from a change to the original strategy rules so both can be scoped clearly.
Offchain’s trading bot and MT4/MT5 development service covers building, repairing and testing rule-based software. Projects needing external connections can also draw on API integration services.
Discuss your trading software project with the platform, written rules and examples of expected behaviour. That gives the scope a testable starting point.