MT5 Grey Label Setup: A Buyer’s Walkthrough From Quote to First Client
Setting up an MT5 grey label is a sequence of purchases and approvals. This walkthrough follows the buyer’s path from the first quote to the first live client, with a checkpoint at each stage so you notice problems while they are cheap to fix.

Stage 1: the quote
Compare two or three setups from the inventory, and request written scope for each. Checkpoint: do you know what is included, what is optional and what the exit terms are? Use the setup comparison guide.
Stage 2: the contract
Check the entity you contract with, the listed limits, support hours and the notice period. Checkpoint: could you explain your rights to a colleague? If not, ask questions before signing.
Stage 3: configuration
Provide your brand assets and agree account types, groups and symbols in writing. Checkpoint: does the configuration match your plan line by line?
Stage 4: supporting systems
Decide which extras to buy now: CRM, payments, website. Checkpoint: can a client register, fund and trade with the minimum set? Our cost guide helps you prioritise.
Stage 5: testing
Test registration, funding, trading and withdrawals with demo and small live accounts. Checkpoint: have you tested a failure, such as a rejected payment? Use the setup checklist.
Stage 6: the first client
Open to a small group first. Checkpoint: are support answers consistent, and do your records match what clients see?
A buyer’s paper trail
Keep a single folder with the quote, the written scope, the signed contract, the configuration document, test results and every confirmation email. Name files with dates.
If anything is disputed later, a tidy paper trail is your best protection. It also makes onboarding a new colleague much faster.
A buyer’s paper trail
At each stage of a setup, collect a document. The collection is your protection if there is a dispute.
| Stage | Document to hold |
|---|---|
| Quote | Signed quote and scope sheet |
| Contract | Signed agreement and attachments |
| Configuration | Export or screenshots of the final setup |
| Supporting systems | Test records for CRM and payments |
| Testing | Test plan and results |
| First client | Notes from the first week |
Keep the documents in one folder with dates.
A worked example of a stage-gated payment
A buyer agrees to pay a deposit on signing, a second payment on delivery of a configured environment and a final payment after acceptance tests pass. During testing, the buyer finds that funding fails for one payment method. Because the final payment is outstanding, the vendor fixes the issue quickly.
Staged payments align incentives. They are a normal request and a reasonable vendor will accept some version of them.
Stage by stage questions
- Quote: what is included, what is not and what are the limits?
- Contract: what are the terms, exit and support?
- Configuration: does it match the scope?
- Supporting systems: who builds them and who tests?
- Testing: what are the acceptance criteria?
- First client: who supports and how are issues handled?
Asking the right question at each stage prevents the expensive surprise later.
Launching with discipline
Choose a small group for the first week, assign a person to watch each of the critical flows and hold a short review each day. Record issues and fixes. After the first week, decide what to improve before wider launch. See our readiness checklist for the final checks.
Choosing the order of work
Buyers sometimes start with the website and leave the contract for later. The order that works best is quote, contract, configuration, integrations, testing and launch, with brand work running in parallel. Starting visible work before the contract is signed risks wasting money if the deal changes.
Draw the sequence on one page and share it with the vendor. Agree who does what at each stage.
Checking each stage before moving on
At the end of each stage, check the deliverable against the scope sheet. Do not move on if there is a gap, because gaps tend to widen. A short check, with a signature from both sides, takes minutes and saves weeks.
Small launch, careful review
Launch to a small group and review daily. Record each issue, who is fixing it and when. After a week, decide whether to widen the launch. A careful start gives you time to fix problems while few clients are affected.
Where buyers lose time in a setup
Delays in a setup rarely come from the platform. They come from decisions that take longer than planned, documents that arrive late and approvals that wait in someone’s inbox. Buyers can shorten the project by preparing these in advance: a short brand pack with logo files, colours and wording; a list of account types with their rules; a list of payment methods; and a named approver for each stage.
On the vendor’s side, delays come from unclear requests. Give instructions in writing, one topic per message, with the deadline and the expected result. A tidy trail of short requests makes it easy for both sides to see what is outstanding.
Keeping control of money during the project
Plan each payment against a deliverable, and keep a simple ledger: what was agreed, what was delivered, what was paid and what remains. If a stage slips, ask what the new date is and whether the payment date moves with it. If the vendor requests extra work, ask for a written estimate before it begins.
A ledger of ten rows is enough. It keeps you honest about what you have committed to, and it gives you a clear picture when a disagreement arises.
A one-page checklist for week one after launch
In the first week after launch: check platform and payments each morning, read every support message, review registration and funding numbers daily, and hold a short meeting each evening. Write down each issue and the fix.
At the end of the week, review the notes and decide what to change before widening the launch. A disciplined first week turns surprises into improvements.
Frequently asked questions
What is the first step in a grey label setup?
A written scope and quote that you have compared with alternatives.
How should I pay?
In stages linked to delivery and acceptance tests.
What documents should I keep?
Quotes, contracts, configuration exports, test records and notes.
How long does setup take?
It depends on scope. Ask for milestones and dependencies.