Platform
Server core, random number generation, money and voucher accounting, recovery after failure, event journal, build signing, an operator console, a separate read-only regulator console, and the terminal client.
Regulated gaming systems
Engineering for gaming systems that have to be verified, not just played.
We design and build the software behind electronic gaming systems — server core, random number generation, money accounting, terminal client — and the evidence an independent testing laboratory needs. For suppliers, distributors and operators in tribal and commercial markets.
01
What changes when a game becomes a gaming system
The art and the game logic can look identical. The architecture can't — and that is where the effort goes.
| Area | Ordinary game | Regulated gaming system |
|---|---|---|
| Builds | Built and released however suits the team. | Reproducible: rebuilding from source produces an identical build with the same signature. |
| Verification | Testing means finding bugs and checking game logic. | The software can be verified on the terminal with the regulator's own tools, without us in the room.1 |
| Randomness | The engine's standard random functions. | Statistical evidence, simulation reconciled with the game math, and a requirement → component → test traceability matrix.2 |
| Communication | A basic API tuned for response time. | A secured terminal network with validation at every step. |
| Trust | Internal components trust each other by default. | Mutual authentication, signed artifacts and a log of tampering attempts. |
| Failure | If it freezes, the player restarts the app. | Pull the plug mid-game: on restart the system returns to a known state and every balance reconciles to the cent.1 |
| People | One developer can write the code and ship the update. | Separation of duties: whoever writes the code is not the person who confirms compliance and signs the release. |
This is why a regulated system costs more than a game with the same art: the complexity lives in the architecture, not in the mechanics.
02
What we build
Themes on an existing platform
New games for a platform that has already been through laboratory testing: art and sound, a signed outcome-to-display mapping, pipeline checks that presentation code can't reach prize logic, regression against the tested core, and the modification package for the lab.
Terminal integration
Terminal client, server communication, and a peripheral layer for bill validators, printers and door sensors built to the manufacturer's documentation — with SAS-based accounting and ticket-in/ticket-out vouchers.
03
Markets
Land-based: Class II and Class III
Bingo-based systems for tribal gaming under NIGC oversight, and Class III gaming devices in compact and commercial jurisdictions.
Online
Real-money and skill-based products for licensed operators: server-authoritative game logic, wallet and KYC integration with the operator's chosen providers, and RNG and game math prepared for the operator's testing laboratory — for example against GLI-19, Interactive Gaming Systems.3
04
How a platform project runs
Five stages, each ending in something you can inspect. A full platform is a six-figure engagement and typically takes around a year to reach a submission-ready package; the laboratory's review time comes on top. A theme on an existing platform is far smaller.
Architecture & certification map
System architecture, the likely set of standards with versions, submission contents and a requirement → component → test matrix. What applies is confirmed with the laboratory and the regulator.
Playable build
The server runs the draw, terminals show the result, one theme end to end.
Money on the machine
Bill validator, printer, vouchers, accounting meters and door sensors working on real hardware.
Hardening
Signatures, security, game history, statistical evidence, operator and regulator consoles.
Submission package
Materials for the independent laboratory, and answers to its findings within our scope.
05
What we don't do — and don't promise
Our responsibility is a system that is ready for independent testing, and engineering support for our part of it. Decisions by independent parties are theirs.
- Promise a certificate. The independent laboratory decides, and the tribal regulator chooses the laboratory.4
- Assign a game class. Classification is a legal determination for the regulator.
- Commit to laboratory or regulator timelines.
- Build hardware — cabinets, bill validators, printers, sensors — or take it through laboratory testing.
- Hold supplier licenses or manage regulator relations on your behalf.
- Take responsibility for third-party platforms, SDKs or hardware we didn't build.
Built by Dev Hub Games
Dev Hub Systems is the regulated-gaming division of Dev Hub Games, a Quebec studio that builds and runs its own games. Same engineers — stricter rules, more evidence.
Start with a technical briefing
A call under NDA: your jurisdiction, what already exists — platform, game math, terminals — and what a system ready for laboratory testing would take. A written proposal follows.
Sources
- 25 CFR 547.8 — software verification and recovery after interruption. Checked 2026-09-16. ↩
- 25 CFR 547.14 — electronic random number generation. Checked 2026-09-16. ↩
- Gaming Laboratories International — GLI Standards — GLI-11 Gaming Devices v3.0; GLI-15 Electronic Bingo and Keno Systems v1.3; GLI-19 Interactive Gaming Systems v3.0. Checked 2026-09-16. ↩
- 25 CFR 547.5(f) — testing laboratories — the TGRA selects the laboratory; it must be independent of the manufacturer and the operator. Checked 2026-09-16. ↩