EA development and source licensing: write a checkable brief
“Build an EA” or “send the source code” is not enough for comparable quotes. Define the environment, feature boundaries, usage rights and deliverables so both parties can assess the work and agree how to accept it.
Use this checklist for new development, adaptation or a source-code license. Fill in what you know and mark unresolved items “to agree together” before asking for an assessment.
Discuss your brief with EAXAU · Studio cooperation
1. Describe the environment and intended use
Specify MT4 or MT5, the terminal version, computer or VPS environment, target instruments and account mode. For an existing project, identify its current version, dependencies, available materials and permitted changes.
Licensing needs depend on intended use. Identify personal use, internal team use, paid services, further development and redistribution separately. If you need source code, also ask for third-party dependencies and their usage restrictions to be identified.
2. Describe features through inputs and outcomes
For each feature, state its trigger, the user's action, the expected display or output, and the response to failure. Replace broad requests such as “easy to use” with behaviour that can be checked.
Illustrative brief: an MT5 panel status display
This is an example of how to write a requirement, not a delivered project or a quote.
| Item | Example requirement | How to check |
|---|---|---|
| Connection status | Display the current connection state and last update time | Change connection conditions in the agreed simulated test environment and inspect the display |
| Help link | Open the specified usage guide | Check that the target opens and matches the version |
| Failure message | Show a clear message if the status cannot be fetched; do not label an old result as current | Simulate a failed response and record the message |
| Change boundary | Update the panel status display only, with no new trading functions | Compare the scope list with the change record |
Projects involving trading functions need separate specifications for triggers, execution, exception handling and test conditions. This interface example is not a complete strategy specification.
3. Specify the deliverables
| Delivery type | Items to identify in the quote |
|---|---|
| Runnable version | File names, version, supported environment, installation and configuration instructions |
| Source code | Included source files, dependency versions, build instructions, required tools and licensing scope |
| Acceptance materials | Test inputs, expected outcomes, actual outcomes and supporting records |
| Operating notes | Update steps, common error messages and issue-reporting process |
| Support | Duration, defect-correction scope, revision allowance and treatment of additional requests |
Not every order includes the whole table. Ask the quote to distinguish included items from those requiring a separate arrangement.
4. Separate acceptance from additional work
Before work starts, agree the test environment, reviewers, feedback period and pass criteria. During acceptance, record “passed” or “revision needed” for each agreed feature, with reproducible steps for any issue.
Work that fails an agreed requirement is recorded for revision. A feature outside the original scope should first be assessed for its effect on fees and timing. Trading outcomes do not replace acceptance of code functionality and deliverables.
A brief you can copy
Project goal: the problem to solve in one sentence.
Delivery type: compiled license / source license / adaptation / new development.
Environment: platform, version, device, instruments and account mode.
Available materials: public links, files you may lawfully supply and documentation.
Features: trigger, action, expected result and exception cases for each item.
Exclusions: functions and services outside this project.
Rights required: licensed user, modification, commercial use, redistribution and exclusivity.
Deliverables: runnable files, source, dependencies, documentation and test records.
Acceptance: environment, examples, pass criteria and feedback process.
Support: desired scope, duration and revision arrangements.
Timing and budget: preferred date, budget range and priorities.
An initial discussion can use a high-level description. Confirm permissions and the handover method before sharing further materials.
Three checks before sending
- Consistent scope: the brief, quote and delivery list describe the same project.
- Clear rights: the files supplied and the permitted uses of those files are specified separately.
- Practical acceptance: both parties can check the outcome using the same examples in the agreed environment.
When ready, ask EAXAU to assess the scope. Feasibility, fees and timing depend on the actual materials.