Who this page is for
An operator with a working platform, ours or another provider's, who wants a front end of their own: a brand that has outgrown its template, a group consolidating brands onto one codebase, or a sportsbook whose interface is the product. The direct answer: build on the platform's API, keep the regulatory components in one shared library, and treat performance targets as acceptance criteria rather than aspirations.
Not for you if the platform itself is the problem. That is a custom platform project. And if you are adding a sportsbook tab to a casino, an iFrame may be enough: the sports betting API page puts the betting front end at 36 to 67 engineer-days over the iFrame.
Template, headless or hybrid
| Themed template | Hybrid | Headless on the API | |
|---|---|---|---|
| What you build | Logo, colours, domain, content | Your own landing and content pages; the platform's lobby, cashier and account screens | Everything the player sees |
| Who maintains the regulatory components | The platform | Split, and the split must be written down | You |
| Time | Weeks | Weeks for the content layer | Months, set by the cashier and the bet slip |
| Control over speed and UX | Little | Full on your pages, none on theirs | Full |
| Adding a licence | The platform ships it | The platform ships its screens; you update yours | You build each market's rules into your components |
| Fits | Launch and market tests | A brand that needs content and SEO control first | A brand whose interface is the reason players choose it |
The common path is the first column at launch and the third in year two, once the brand knows which screens players actually use. On our turnkey casino both are available against the same casino API.
What regulators check on screen
These are the elements a regulator or a licence condition places in the interface itself. Build each one as a component that every brand and market inherits, so a rule change is one release rather than one per brand.
| Market | What must be on screen |
|---|---|
| Curaçao | The Green Seal, issued only once the licence is granted. Since 15 October 2025 an orange seal of the old sub-licence model on a domain puts the operator in breach. |
| Tobique | A footer with the Commission's validation shield and ten policy links |
| Tuvalu | The licence seal on the site, with 99.9% uptime as a licence condition |
| Finland, from 1 July 2027 | Strong electronic identification at registration, and personal deposit limits set before play starts |
| Cyprus | A .com.cy domain for a Class B sportsbook |
| Brazil | Fixed-odds betting only on a bet.br domain, from 1 January 2025 |
| Germany | A clearly labelled button for an immediate 24-hour block, displayed permanently wherever play is possible (GlüStV 2021, §6i(3)) |
| United Kingdom | Reality checks at a frequency the customer sets, which stay on screen until acknowledged; elapsed session time shown throughout casino play (RTS 13B, 13C) |
We file licences in the first five and none of the last three. They are included because their rules are the strictest of their kind, and a component built to them covers most other markets too.
Performance
Google's Core Web Vitals give three targets, measured at the 75th percentile of page loads, separately for mobile and desktop: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less. Gambling front ends miss them in predictable places.
| Where it breaks | Metric it hurts | The usual fix |
|---|---|---|
| Lobby with hundreds of game thumbnails | LCP | Load the first screen's images first, lazy-load the rest, serve sized images |
| Live odds updating continuously | INP | Batch updates and re-render only the prices that changed |
| Promotional banners and odds rows that load late | CLS | Reserve their space before content arrives |
| Game launch inside the page | INP, LCP | Open the game window only after the launch URL returns, with a sized placeholder |
| Consent banner, chat widget, analytics tags | All three | Load after the first interaction, not before the lobby |
Write the targets into acceptance as field data from real players, not only a lab score from one office connection.
Localisation
A localised gambling front end is more than a translation. Each market brings its own currency and minor units, odds format, date format, legal texts and payment methods, and the licence may decide which of these you can show. A Finnish brand cannot show a crypto cashier or a welcome bonus. A brand on an Anjouan licence must block the countries on its restricted list. Write each market as configuration, not as a branch of the code, so a new market is a set of values rather than a project. And write the copy for the market's own players: a literal translation of the English site reads as one, and players notice.
What you should own at the end
- The source code, the component library and the design files, assigned to you on payment.
- The build pipeline and the infrastructure code needed to deploy it without us.
- A list of every third-party package and its licence.
- The regulatory component checklist per market, with the version of each rule it was built to.
- Access to the content management system in your own account. The casino and sportsbook CMS page covers that layer.
Where front-end projects go wrong
- Regulatory components copied per brand. A rule changes and five brands need five fixes, and one gets missed.
- The cashier left to the end. It is the screen with the most licence rules and the most payment methods, and it sets the launch date.
- Speed measured on the designer's laptop. Players on mid-range phones and mobile networks see a different site.
- Game windows that block the page. A slow studio makes the whole lobby feel broken.
Questions to put to any front-end team, including us
- Which regulatory components exist as shared code, and which market rule version is each built to?
- What are the Core Web Vitals targets in the contract, and are they measured in field data?
- How is a new market added: configuration, or new code?
- What do we receive besides source code?
- Who updates the regulatory components when a rule changes after handover?
Frequently asked
Can we keep the platform's cashier and build everything else?
Yes. That is the hybrid column above, and it is a sound first step, because the cashier carries the most licence and payment rules. Write down which side maintains each screen.
Does a custom front end need certification?
The games and the platform are what labs certify. The front end has to carry the licence's display rules and player-protection controls, and a regulator can check those on the live site. Treat the table above as the acceptance list.
Native apps or web?
Web first in most cases, because one codebase serves every market. A native app adds app-store rules on gambling, which differ by store and by country, to the licence rules.
Can the same front end serve casino and sportsbook?
Yes, on one account and one wallet, which is what players expect. The bet slip and live odds need their own performance work; the casino lobby needs image work.