MT5 White Label Launch Timeline: Critical Path, Dependencies and Acceptance Gates
A launch calendar hides the structure that decides whether you hit it. Express the plan as a dependency graph with owners and acceptance gates, then derive dates from durations and lead times. The schedule below is an illustrative example, not a commitment.
Define the work packages
Typical packages: contract and scope; platform provisioning; branding; groups and symbols; hosting and monitoring; CRM integration; payment integration; liquidity bridge; testing; training; go-live.
Each needs an owner, an input, a deliverable and a duration range. Components are listed in the white label turnkey guide.
Map the dependencies
Platform provisioning precedes configuration. Configuration precedes integration tests. Payment approval and bridge agreements run in parallel with the platform but gate acceptance testing. Banking gates payment approval.
Draw the graph and mark the critical path.
Illustrative sequence
- Weeks 1–2: contract, kickoff, requirements; start banking and approvals.
- Weeks 3–4: provisioning, branding, groups and symbols.
- Weeks 5–6: CRM, payments and bridge integration.
- Weeks 7–8: acceptance testing, training and soft launch.
Parallel items can lengthen or shorten each block.
Acceptance gates
Define pass criteria for each gate before work starts: configuration matches the register, integrations pass the written test cases, failure cases behave as specified. Do not move to the next gate with open critical defects.
Risk register
Log risks with likelihood, impact and owner: late approvals, third-party delays, scope changes. Review weekly. See also the readiness checklist.
Duration ranges, not points
Record each work package as a range, such as optimistic, expected and pessimistic duration, and compute the schedule from the ranges. Third-party items deserve the widest ranges.
Present the schedule as a band with a confidence level rather than a single date. Re-forecast weekly as actuals replace estimates.
Work packages and dependencies
Decompose the launch into work packages with clear outputs: contract and scope, environment provisioning, branding, group and symbol configuration, CRM integration, payment integration, liquidity bridge, testing, training, compliance inputs and launch. For each, list predecessors, owner, effort and external dependencies.
Build the dependency graph and identify the critical path. Anything on the critical path deserves a risk review and a named backup.
A schedule with ranges
| Work package | Optimistic | Expected | Pessimistic | Dependency |
|---|---|---|---|---|
| Environment ready | 2 weeks | 3 weeks | 5 weeks | Contract |
| Branding applied | 1 week | 2 weeks | 3 weeks | Brand assets |
| CRM integrated | 2 weeks | 4 weeks | 7 weeks | Environment, access |
| Payments integrated | 3 weeks | 6 weeks | 12 weeks | Provider approval |
| Testing | 2 weeks | 3 weeks | 5 weeks | Integrations |
The numbers are illustrative placeholders. Replace them with ranges from your vendors and compute the schedule from the ranges, not from single points.
Acceptance gates
Define gates between phases with explicit criteria: environment gate (access, configuration export), integration gate (test evidence for each workflow), readiness gate (rehearsal passed, staff trained, runbooks delivered). A gate is passed on evidence, not on assertion.
Tie milestone payments to gates where possible.
Risk register
Maintain a register with risk, likelihood, impact, mitigation, owner and trigger. Typical entries: payment provider approval delay, late brand assets, defect found late in testing, key person unavailable. Review weekly and update the forecast when a risk materialises.
See our readiness checklist for launch gate criteria.
Worked example: critical path shift
Payments integration is expected at six weeks but the provider’s review requests additional documents. The delay moves the integration test window and, because acceptance testing depends on payments, the launch gate. The team re-forecasts using the pessimistic range for payments and reorders work: testing of other workflows proceeds, the payment test is scheduled when approval arrives, and a limited launch without that method is evaluated.
Re-forecasting weekly with updated ranges keeps stakeholders informed and exposes decisions early, when options still exist.
Launch readiness and ramp
Plan a ramp: internal users, friendly clients, a limited campaign, then open registration. Define thresholds for each step and a pause procedure.
After go-live, hold a retrospective comparing planned and actual durations by work package and update the estimation parameters for future projects.
Communication and reporting cadence
Define a reporting cadence: a weekly status with progress against work packages, forecast dates from the latest ranges, top risks and decisions required. Keep it to one page and send it to the same group each week. Hold a short fortnightly steering meeting for decisions and escalations.
Consistent reporting makes slippage visible early and creates a record that supports commercial discussions when dependencies on third parties cause delay.
Frequently asked questions
How do I build a realistic launch schedule?
Use work packages, dependencies and duration ranges from vendors, then compute the critical path.
What delays launches most?
Third-party approvals, late inputs and defects found late.
How should payments be tied to the schedule?
To acceptance gates with evidence.
How often should the risk register be reviewed?
Weekly during the project.