Every vendor in this market claims to be platform-agnostic. None of them can credibly mean it, because the claim requires being willing to recommend nothing — including their own product — and a vendor’s business model does not survive that sentence.
I mean it as a design property of how I work, not a virtue I’m claiming. The difference matters, and it’s worth being precise about why.
Independence is not the same as neutrality
A consultant who sells advice about platforms is not automatically independent of them — advisory firms take referral fees, maintain partner tiers, and build practices around specific vendor ecosystems, all while describing themselves as agnostic. That’s not dishonesty exactly; it’s structural. Their commercial incentive is aligned with a recommendation being made, because a recommendation is the product. Mine isn’t. I’ve told organisations, in writing, that the correct answer was to buy nothing — keep the system already in place, fix the data model underneath it, and walk away from a migration that would have cost six figures and solved nothing. That’s not a hypothetical stance. It’s a receipt, and it’s the kind of receipt a vendor-aligned advisor structurally cannot produce, because “buy nothing” doesn’t generate a fee for anyone whose business model depends on a purchase happening.
Why the model has to be right before agnosticism is even possible
Here is the part that’s easy to miss: you can only be credibly platform-agnostic once the data model is sound. If the model is broken, every tool conversation becomes a search for a platform clever enough to compensate for the mess underneath — and that search never ends, because no tool can permanently patch a model that was never designed to carry the obligation in the first place. Each new platform becomes load-bearing in exactly the way the last one was, and the business quietly depends on it, and “agnostic” becomes a claim nobody can actually test.
Fix the model first, and the calculus inverts. A sound model can be served by more than one credible tool, which means the tool stops being a strategic bet and becomes what it always should have been: a replaceable implementation detail. That’s the actual target. Not finding the best tool — reaching a model good enough that the tool question stops mattering as much as everyone assumed it would.
What agnosticism looks like when it’s tested
An iGaming operator under an MGA or comparable licence needs to demonstrate responsible-gambling controls — self-exclusion honoured across every product, risk indicators tracked per player, interventions logged and auditable. The market is full of player-account-management platforms that promise to solve this out of the box, and most of them can, provided the operator’s own definition of “player” is singular and consistent across sportsbook, casino, and any white-label skins running alongside. Where it isn’t — where a self-excluded player can still open a session because the exclusion lived in one system and not the others — no platform migration fixes that, because the gap isn’t a feature the new platform lacks. It’s an identity model that was never unified in the first place. Agnosticism here means being willing to say the fix is a data project, not a procurement one, even when a vendor is standing by with a compelling alternative platform and a discount for signing this quarter.
What this changes about how an engagement runs
Practically, it means the vendor conversation happens last, not first, and it happens without a stake in the outcome. It means I will tell you a widely-used platform is wrong for your specific obligation even when it is the market leader, and tell you a boring, unfashionable system is right when it already does the job the model requires. It means the deliverable is occasionally “stop the project,” which is the single sentence a vendor in the room can never say, however honest they otherwise are.
It also means agnosticism has a boundary worth naming: it applies to which platform, not to whether your evidence obligations get met. I am agnostic about the tool. I am not agnostic about whether you can prove what regulation — covered on the first page in this chain — requires you to prove. That’s not a contradiction. It’s the whole structure of the argument, start to finish: the obligation defines the proof, the data model carries the proof, and only then does a tool get chosen to serve a model that no longer needs saving.
This is also, frankly, the least comfortable part of the position to hold. Recommending nothing doesn’t photograph well in a proposal, and “the incumbent system is fine, the model wasn’t” is a harder sentence to deliver in a room that expected a shortlist. I’d rather deliver the harder sentence than the comfortable one that costs you a migration you didn’t need.
See the full chain on How I Work, or read where this thinking gets applied to a live regulatory obligation at CPS 230 or the Cyber Resilience Act.