Platform decisions fail in a characteristic way: they are made too big, too early. A multi-year commitment, signed on the strength of demonstrations and references, before the platform has ever touched the institution’s own data, rules or people. By the time reality reports back, the sunk cost is doing the deciding.
The alternative is not more evaluation. Evaluation has diminishing returns — another workshop, another scoring matrix, another vendor bake-off measuring who demos best. The alternative is a smaller decision: ninety days, real services, your environment, your team in the room.
What ninety days must prove
A proof that only proves the vendor can demo is worthless — you knew that already. Structure the ninety days so that by the end, four claims have been tested against your own reality:
- Weeks one and two — discovery: your actual services, data and integrations mapped into a working model. If the vendor’s method can’t absorb your mess, better to learn it in week two.
- Weeks three to six — configuration: first services stood up as governed workflows, with your staff configuring alongside the vendor’s. Watch who holds the keyboard.
- Weeks seven to ten — integration and hardening: identity, payments, legacy estates, and a security review against your standards, not the vendor’s brochure.
- Weeks twelve to sixteen — first go-live: real users, real requests, in production. Small in scope, real in consequence.
The two failure modes to design against
The first failure mode is the pilot that cannot die — a proof so entangled with promises that ending it feels like a crisis. Guard against it contractually: the ninety days must be priced, scoped and terminable on its own, with everything produced — definitions, configurations, documentation — belonging to you either way. A vendor who resists that clause has told you something useful, cheaply.
The second is the pilot that cannot live — a sandboxed toy on synthetic data that proves nothing because it risks nothing. Guard against it operationally: insist on one service that matters, one integration that is genuinely ugly, and at least two of your own staff doing configuration by week six. Evidence only accumulates where reality is allowed in.
Decide on evidence, then decide big
Ninety days later you hold something rare in institutional technology: a decision you can make from strength. A live service, measured cycle times, your team’s first-hand account of the tooling, and a vendor who has been watched working rather than presenting. If the evidence is good, commit — and the platform decision that follows is large but no longer blind. If it isn’t, you have spent a quarter and kept everything you built.
Either way, the institution decided. That — more than any feature — is what the ninety-day structure buys: it returns the decision to the buyer, where it belonged all along.