# 6. Which demonstration would reveal that a platform fits our business—not just the supplier’s script?

**A good answer should prescribe exception tests using buyer-representative data.** The demonstration should show how work behaves when assumptions fail.

**Why it matters to buyers.** In his first-person account of GRC tooling at GitLab, Ayoub Fandi describes moving from surface-level requirements towards interviews about internal customers’ business problems. Treat this as a practitioner account worth probing, not a generalised failure-rate study. ([grcengineer.com](https://grcengineer.com/p/build-vs-buy-we-did-both-here-s-what-we-learned-rsac-2026-talk-summary))

**Put it to:** Ayoub Fandi and Michael Rasmussen.

**A strong answer should define a common demonstration script:**

| Scenario | Proposed observable acceptance evidence |
|---|---|
| Overdue remediation | Reassignment, escalation and original due-date history remain visible. |
| Disputed assessment | Challenge, rationale, approval and prior score can be reconstructed. |
| Failed integration | The failure and affected records are identifiable; stale evidence is not silently treated as current. |
| Restricted evidence | An unauthorised user cannot obtain the content through the tested interface, search or export route. |
| Administrator change | The buyer changes a field or approval step and demonstrates testing and rollback. |
| Bulk export | Records, relationships and the agreed supporting material can be reconciled outside the platform. |

**Ask for proof:** an evaluator log identifying the exact package, configuration, custom work and evidence shown.

Record **demonstrated**, **partially demonstrated**, **not demonstrated** and **roadmap** separately. Do not convert “not demonstrated” into an unsupported statement that the product lacks the capability.

**Follow-up:** “Which part of what we saw would our administrator be unable to reproduce without your team?”

> **Expert quote — pending interview:** [Insert approved quotation and attribution.]