Comparing iGaming Vendors When Every Demo Looks Good

Every iGaming platform demo looks good. The supplier has run the same sequence hundreds of times, on scrubbed demo data, on their fastest environment, with a presenter who knows exactly which buttons to avoid. After a few sessions, the demos blur together and buying teams fall back on gut feel, which is precisely when expensive mistakes get made. The fix is not more demos. It is a comparison method that grades what each supplier actually demonstrated against the same written requirements.

This is the method I have used with operators choosing between casino, sportsbook and combined platforms. It takes discipline rather than budget: a shared requirement list, a gate-versus-preference split, an evidence scale, and a decision record at the end. Run it properly and the right choice usually becomes obvious without anyone needing to be convinced.

Start with the Buying Team's Priorities, Not the Supplier's Script

Before the first demo, get product, operations, finance and technical staff in one room and have each name what they need the platform to do. Product cares about the player experience and lobby control. Operations cares about back-office workflows, settlement and player support tooling. Finance cares about reporting, reconciliation and exports. Technical staff care about environments, access, and how the thing behaves under load. None of these perspectives is complete alone.

Write the combined list as testable requirements, not aspirations. "Good reporting" is untestable. "Finance can export a daily settlement report broken down by game, currency and payment method without contacting support" is testable. Aim for thirty to sixty requirements; fewer and you have not done the work, more and the team will stop applying care to each one. This list feeds your platform RFP if you run one, and it feeds the demo agenda itself, since the best demos are the ones where the buyer writes the script.

Separate Gates from Preferences

A mandatory gate is a condition the proposed operation needs in order to proceed. A preference improves the experience but can be traded. This distinction sounds obvious and is violated constantly, because weighted-score spreadsheets treat a missing requirement as a zero and a dazzled preference as a ten, and the average quietly forgives the zero.

Illustrative example: your finance controller requires a settlement export in a specific format to feed the existing accounting system. That is a gate. If a supplier fails it, the product is out, regardless of how elegant the lobby editor is, because the alternative is manual reconciliation work forever. Meanwhile your CRM manager prefers drag-and-drop segment builders over filter-based ones. That is a preference, and it may be traded for a supplier that passes the gate. Gates fail the deal; preferences rank the survivors. Score them in that sequence and the comparison stays honest.

Grade Evidence, Not Confidence

Use a four-point scale for every requirement, applied identically across suppliers:

• Unknown: not asked, or answered with a deflection. Mark it honestly.
• Described: the supplier explained the capability verbally or in documentation, but it was not shown.
• Demonstrated: shown working in the session, against your requirement, on something resembling the proposed product.
• Accepted in scope: the supplier has confirmed in writing that the requirement is inside the proposed agreement, either as existing functionality or as committed development.

A persuasive answer is not evidence. A charming account director who describes a reconciliation module fluently has earned a "described", not a "demonstrated". Record release and conditions alongside the grade: which product version was shown, whether the feature was live or running in a preview environment, and whether it depends on a specific third-party provider. A wallet feature that only works with one specific PSP is a materially different proposition from an open integration, and the comparison should carry that qualification into the final document.

Requirement (Illustrative)	Gate or Preference	Vendor A	Vendor B	Vendor C
Daily settlement export in finance's required format	Gate	Demonstrated	Described	Accepted in scope (development)
Combined casino and sportsbook wallet	Gate	Demonstrated	Demonstrated	Unknown
Operator-controlled content and lobby ordering	Preference	Demonstrated	Unknown	Described
Bonus and promotion configuration without vendor tickets	Preference	Described	Demonstrated	Demonstrated
Gate outcome	—	Passes	Conditional (export only described)	Conditional (wallet unknown)

Read the table the way a COO would. Vendor A passes both gates with demonstrated evidence, so its preference scores matter. Vendors B and C stay in the room only as conditional candidates, and the condition is named in writing, not smoothed over. One more rule that saves careers: do not invent scores for suppliers you have not evaluated. Public marketing pages are good for forming questions. They are not enough to produce a defensible head-to-head ranking, and a spreadsheet full of assumed numbers will be quoted back at you in a board meeting long after you forgot they were guesses.

Compare the People and the Process

Demo quality is largely a property of the presenter. What transfers into the contract term is how the supplier organisation handles gaps. During your sessions, deliberately ask about something you suspect is missing, and watch the response. A supplier that names an owner, explains the limitation plainly, and commits to a realistic next step is showing you how it will behave for the next three to five years. A supplier that blurs the answer, or promises everything will be in the next release, is also showing you.

Force the as-is versus development distinction into the open, because it decides what you are actually buying. Some platforms are sold as an existing SaaS product, with anything beyond it scoped and agreed separately. Others bundle bespoke development into the pitch. Neither model is wrong, but you must know which one is on the table, because "yes, we can do that" means something entirely different when it carries a scoped project behind it. Our article on SaaS scope and customisation and the comparison of SaaS versus custom build go deeper on that split. Similarly, the white label, turnkey and SaaS distinction changes what responsibilities each party holds, so clarify the delivery model before grading anything.

Clear exclusions make a proposal easier to evaluate than a long list of unexplained inclusions. A supplier that writes "not included: loyalty engine; available as separately scoped modification" is being precise. A supplier whose proposal implies everything is included has simply deferred the argument to implementation, where it will cost goodwill on both sides. This does not replace contract review; it tells the lawyers where to focus.

What to Ask Beyond the Demo

A demonstration shows the product at a moment in time. The questions below probe how the product behaves across the contract term, and the answers feed directly into your evidence grades:

• Release and update handling. How are updates deployed, can you preview them, and what notice do you get when behaviour changes? A platform that reconfigures your lobby without warning creates operational incidents you then grade against your own support process.
• Third-party dependency drift. Game providers, payment APIs and odds feeds change their interfaces. Ask who absorbs that change — the platform team as routine maintenance, or you as a scoped project — because the honest answer rewrites several "demonstrated" grades.
• Data access and exit. What exports exist for players, balances and history, and what does the supplier provide if the contract ends? A vendor that cannot describe its exit path has not finished its own product thinking, and your future migration options depend on it.
• Support mechanics. Severity definitions, escalation path, maintenance notice and post-incident reporting. Grade these with the same evidence scale, using the framework in our support and SLA guide, rather than accepting a "24/7" badge.

None of these questions are hostile. Suppliers with a mature product answer them quickly and specifically. Suppliers who struggle usually struggle with the deployment itself, which is exactly what the comparison exists to find before signature.

Worked Scenario: Three Suppliers, One Gate

Illustrative case, composite rather than a specific client. An operator runs a casino brand and is adding a sportsbook. Three suppliers demo. All three show polished sportsbook front ends. The buying team's written list includes two gates: a settlement export in the format finance's accounting system consumes, and a combined wallet across casino and sportsbook so players move between products without separate balances. Without the split, Vendor C would have won on aggregate score, mostly on the strength of a beautiful betslip. With the split, Vendor C cannot confirm the wallet at all, and Vendor B has only described the export. Vendor A, with the least glamorous demo, is the only one that survives the gates. The preference comparison then ranks the remaining candidates, and the decision writes itself. Structure beats presentation. The postscript matters too: because the gates and evidence grades were written down, when Vendor B was later chosen as a conditional fallback, everyone knew precisely which condition had to close — the export had to move from "described" to "demonstrated" — and who owned chasing it. Unwritten conditional decisions have a way of becoming signed surprises.

End with a Decision Record

Whatever you choose, write it down. The decision record states why the chosen option fits your requirements, what remains unresolved, and who accepted each trade-off. If a mandatory question is still open, record a conditional decision with a named owner and a date. Do not declare the review complete while a gate is unresolved; that is how organisations sign contracts against products that were never actually confirmed.

One practical point on authorship: the person who writes the record should not be the person who ran the demos. Rotation matters. The demo runner inevitably remembers the presentation; the writer should work only from the graded evidence and the session notes. Two sets of eyes on the same facts is a cheap control that catches the moment enthusiasm outran the record.

The record has a second life. Eighteen months later, when an integration behaves differently from what the team remembers being shown, the record with its evidence grades will tell you what was demonstrated, what was described, and what was merely assumed. That is the difference between a supplier conversation and an accusation.

When you are ready to apply this, the operator scorecard gives you the requirement framework, and Trade Lab Solutions will run ScaleBets through it alongside you. ScaleBets is a casino and sportsbook SaaS supplied as-is, with custom modifications scoped separately, which means every requirement in your comparison receives an evidence grade against the existing product, and anything beyond it is named as scoped work rather than absorbed into a vague inclusion. That is the honest version of the demo.