Prop Firm Software Demo Checklist: Make Every Vendor Prove the Same Things
Vendor demos are designed to show strengths. Buyer demos should expose fit, dependencies and failure handling. Give every shortlisted provider the same operating scenarios and score what is demonstrated—not presentation quality.
Before the demo: send one script
Give candidates the same challenge rules, platform requirement, lifecycle, volume assumptions and integrations in advance. Ask them to demonstrate the configured workflow live where practical and identify anything that is manual, partner-dependent, custom or roadmap.
1–5: Product and checkout
- Create a new two-phase challenge product.
- Change profit target and drawdown rules without development.
- Apply a campaign/affiliate attribution identifier.
- Complete a test checkout.
- Show the resulting customer, order and attribution record in admin.
6–10: Trading account provisioning
- Provision the trading account automatically from purchase.
- Show credentials delivery and account state.
- Reset or retry an account.
- Move an account from phase one to phase two.
- Force a provisioning failure and show detection, retry and escalation.
11–15: Risk and breaches
- Trigger daily-loss logic using a realistic equity scenario.
- Trigger maximum-loss logic.
- Show the exact rule version bound to the account.
- Open audit evidence for a breach.
- Demonstrate behavior when trading data is delayed or unavailable.
16–19: KYC and payouts
- Move a customer into KYC review.
- Show failed/manual-review/unsupported-market state.
- Create a payout request and show approval controls.
- Show how risk/KYC state blocks or flags payout and how reconciliation closes the lifecycle.
20–23: Operations and support
- Search one customer and reconstruct the complete lifecycle.
- Show administrator roles and permissions.
- Show audit logs for administrator actions.
- Show an incident/error view and the escalation path rather than only a happy-path dashboard.
24–26: Integration architecture
- Open API/webhook documentation where available.
- Show a real event delivery, failure and retry behavior.
- Explain which trading, KYC, PSP, market-data and messaging contracts sit outside the platform and who supports each boundary.
27–30: Data, migration and exit
- Show the import/migration data model.
- Explain parallel-run, cutover and rollback procedure.
- Export customer/account/transaction data in a usable format.
- Show the contract/scope governing termination, retention, export and migration assistance.
Score evidence, not confidence
| Score | Meaning | Confidence |
|---|---|---|
| 2 | Demonstrated live with relevant configuration | High if backed by docs/scope |
| 1 | Supported but not demonstrated, or manual/partner dependency remains | Medium/low |
| 0 | Unavailable, unclear, roadmap or unpriced custom work | Low |
A perfect 60 is not the objective. Apply your own knockout criteria first, then use the weighted selection scorecard. A vendor that fails a mandatory requirement should not win through points elsewhere.
Three red flags during a demo
- The presenter repeatedly changes the scenario instead of demonstrating yours.
- Critical integrations are described by logo/name but no ownership, event flow or failure handling is shown.
- Material capabilities are promised verbally but excluded from written scope, pricing or delivery timing.
After the demo: convert claims into the quote
Record unresolved items and require the commercial proposal to identify what is included, external, optional, custom or unknown. Then use quote comparison so the demo winner is not automatically the commercial winner.
Do not confuse a demo with acceptance
A demo proves capability in a controlled session. Implementation acceptance proves your production configuration works. Before go-live, rerun critical purchase, provisioning, breach, KYC, payout, refund, outage and attribution scenarios using the acceptance framework.