You Play Twenty Titles Before You License HTML5 Games. Pick Them by Failure Mode, Not by Fun.

Nobody plays a thousand titles before they license HTML5 games. You get a sample of about twenty, and how you pick it decides what launch week costs you.

The moment always looks the same. The shortlist is down to two or three suppliers, somebody has sent a spreadsheet with a thousand-odd rows in it, and there is a demo link that expires in a fortnight. Procurement wants a recommendation by Friday. Nobody is going to play a thousand games, and everyone in the room quietly knows it. So two or three people open the demo, click the titles with the best thumbnails, agree the games seem fine, and the deal gets signed on impressions.

That is a sample of roughly twenty titles being spent on the wrong question. Twenty games can tell you a great deal about a catalogue. What they cannot tell you is whether the games are good — and good was never the risk.

Worth noting how little agreement there is on the size of the market you are buying into. The Business Research Company's Browser Games Global Market Report, published July 2026, puts browser games at $7.81 billion in 2025 rising to $8.01 billion in 2026 — a 2.6% CAGR, essentially flat. Business Research Insights, measuring HTML5 games as a category rather than browser games as a channel, lands near $6.0 billion for 2026 and forecasts 6.34% CAGR to 2035. Overlapping definitions, a two-billion-dollar gap, growth rates differing by more than double. Treat any single figure here as directional, not planning input.

🎲 Twenty Out of a Thousand Is a Stronger Sample Than It Feels

Start with the arithmetic, because it is more encouraging than most buyers assume, and because it changes what you should be looking for.

Suppose some defect runs through a catalogue — desktop-first control schemes, no localisation files, an ad callback that does not exist in the build. Call the share of titles carrying it the defect rate. If you play twenty titles chosen without bias, the chance you hit at least one carrier is one minus the complement of that rate, raised to the twentieth power. Run it:

• Defect present in 20% of the catalogue: a twenty-title sample surfaces it 98.8% of the time.
• Present in 10%: 87.8%.
• Present in 5%: 64.2%.
• Present in 2%: 33.2%.
• Present in 1%: 18.2%.

That is the binomial; drawing twenty from a finite catalogue is technically hypergeometric, but at a ratio of twenty to a thousand the difference is not worth the algebra.

Read the top of that list and the bottom of it as two separate messages. A twenty-title sample is a genuinely powerful instrument for catching anything systemic. If a fifth of the catalogue was built for mouse input, you will find it. If a tenth of it has no way to fire a rewarded-video callback, you will almost certainly find that too. What the sample cannot do is find rare problems. A defect sitting in 1% of a thousand titles is ten broken games, and you will miss them five times out of six.

That splits the whole exercise cleanly in two: use the sample to test for systemic defects, and use the contract to handle rare ones. Buyers routinely get this backwards. They play twenty games hunting for individual duds — which the sample is bad at — and then sign an agreement with no replacement clause, which is the only tool that actually addresses duds.

If you want to know what more testing buys: reaching 95% confidence of catching a 10% defect takes 29 titles. For a 5% defect, 59. For 2%, 149. So the honest answer to "should we test more than twenty?" is that going from 20 to 29 meaningfully firms up your read on systemic issues, and going past about 60 is a research project, not a procurement step.

🧬 Stratify the Sample. Do Not Randomise It.

Everything above assumes an unbiased draw. Pure randomness is the right method only when you have no prior information about how the population varies. You have plenty.

Catalogues are sediment, not a uniform block. A supplier operating for years has titles from several build eras, several engines, and several sets of assumptions about what a player is holding. Failure modes cluster by layer. Stratify along the axes where you know variation lives, and give each stratum at least two titles — one is an anecdote:

• Build vintage. Oldest titles, middle of the catalogue, most recent additions. The oldest layer is where desktop assumptions and dead ad SDKs live.
• Engine and framework. Ask what the catalogue was built in and sample across it, not just the house engine.
• Genre and control scheme. A match-3, a runner, a driving game, a point-and-click, a shooter. Control input varies far more than genre labels suggest.
• File weight. Explicitly pick the two or three heaviest titles you are offered. They set your worst case, and worst case is what your support inbox is about.
• Format. If the deal covers both HTML5 and Android builds, test both. An APK is not a wrapper around a passing web build, and a passing web build does not predict one.

A workable split of twenty: six across build vintage, four across engines, five across control schemes, three heaviest-file titles, two format crossovers. Adjust to the use case — a carrier deck cares most about weight, a kids' portal about control simplicity.

⏱️ Six Things Worth Spending the Sample On

1. Cold-load weight, on a throttled connection

Test cold cache, every time. A second play of the same title tells you nothing, and this is the most common way an evaluation lies to itself. Google's page-speed benchmarks, drawing on Google/SOASTA research from 2017, put it plainly: as load time goes from one second to ten, the probability of a mobile visitor bouncing rises 123%. The study is nearly a decade old; the impatience it measured has not improved. Record time-to-first-input, not time-to-loaded.

2. Control scheme under a thumb

Play every sampled title one-handed on a phone before you play it anywhere else. Games designed around a mouse survive a touch port on paper and die in the hand: hit targets sized for a cursor, controls parked under the browser chrome, drag gestures that fight the page scroll.

3. The device floor, which is lower than your office

Per Statcounter's Android version share for July 2026, Android 16 sits at 25.49%, Android 15 at 17.19%, Android 13 at 14.78% and Android 14 at 13.14% — leaving roughly 29% of Android devices worldwide on Android 12 or older. Statcounter's mobile browser figures for the same month put Chrome at 66.79%, Safari at 25.44% and Samsung Internet at 2.48%. So the bench needs one genuinely old mid-range Android and one iPhone on Safari. A pair of current flagships tells you nothing about the market you are buying for.

4. Where the text actually lives

Open the build. If the strings are baked into sprite sheets or hardcoded in the bundle, localisation is a re-export request to the licensor for every title, every language, forever. If they sit in an editable file you receive, it is a translation job you control. This single distinction can swing the cost of a multi-language launch by an order of magnitude, and it is invisible from playing the game.

5. Whether the monetization hook exists at all

Do not accept "supports ads" as an answer. Ask which specific callback fires, when, and whether you can wire your own mediation to it. Then verify it in the sampled build. A catalogue where the ad integration is the licensor's and not yours is a revenue-share conversation wearing the costume of a technical feature.

6. Provenance and the paperwork behind it

For each sampled title, ask who built it and whether the supplier holds the rights it is granting you. A supplier that can answer this instantly for twenty random titles can probably answer it for a thousand. A supplier that has to go and check is telling you something about the other 980.

🗓️ Running Twenty Titles in One Working Week

This is a week of work for one person, not a quarter for a committee. Make it repeatable so you can run it identically against each shortlisted supplier — a comparison is worthless if each supplier was measured differently.

• Fix the bench first. One old mid-range Android, one current Android, one iPhone, one desktop browser. Same four devices for every supplier.
• Ten minutes per title, timed. Cold load, first input, three minutes of play, then straight to the scoresheet. Twenty titles is under four hours of hands-on.
• One scoresheet, same columns. Load time, first-input time, touch usability, visual defects, text handling, ad hook present, build format. Numbers and yes/no only — no adjectives.
• Log the misses, not just the failures. Titles you could not test, links that were dead, builds that were not supplied. Those gaps are data about the supplier's operations.
• Write the finding as a rate, not a story. "Four of twenty had unusable touch controls" is a procurement input. "Some of the older games felt clunky" is not.

📄 What the Sample Cannot Tell You — Put That in the Contract

Once you accept that twenty titles cannot find rare defects, the remedy stops being more testing and becomes better drafting. Four clauses do the work your sample cannot:

• An acceptance window. A defined period after delivery in which you can reject titles that fail an agreed standard, with the standard written down — not "reasonable quality" but the thresholds from your scoresheet.
• Replacement, not refund. For a catalogue deal you generally want the right to swap rejected titles for others of equivalent standing. Refunds shrink your catalogue; replacements keep it whole.
• A defect-rate trigger. If more than an agreed share of delivered titles fails acceptance, the whole delivery is renegotiable. This is the clause that protects you from the systemic problem your twenty happened to miss.
• Maintenance obligations with a clock. Browsers and Android both move on schedules nobody consults you about. Establish who fixes a title that breaks after delivery, and inside what window.

Extend the same discipline to Android. Per Google Play's published target API level requirements, existing apps must target Android 15 (API level 35) or higher from 31 August 2026, new apps and updates must target Android 16 from that date, and extensions run to 1 November 2026. If your licence covers APK builds, who rebuilds against a new target API — and how often — belongs in the contract, not in a support ticket eighteen months from now.

🔍 Suppliers Differ Enormously in What They Let You Test

Testability itself is a criterion, and it separates the supplier categories more sharply than price does. Compare types, not names:

• Self-serve asset marketplaces. You generally buy first and inspect after. Cheap per title and genuinely useful for a single experiment, but the pre-purchase sample is a video and a screenshot.
• Free game feeds and embed networks. Nothing to test but the embed, because you never receive a build. Fine when the embed is the product; useless if you need to modify, rebrand or ship the title inside an app.
• Single-title studios. Full access, deep answers, one game. If what you need is one bespoke game for a campaign or a booth, this is frequently the right route and no catalogue licence beats it — say so internally rather than forcing a catalogue deal into a single-title problem.
• Aggregators and publishers. Breadth, variable provenance. The useful question is whether they can answer question six above for a random twenty.
• Full-service licensors. Should be able to hand you real builds under NDA across strata you nominate, plus rights answers per title. If a licensor will not let you choose the sample, that is the finding.
• Building in-house. Nothing to sample, because the risk is yours end to end. Rational when games are your core product and you intend to staff for it permanently; expensive when you need volume by a date.

The tell across all six is simple: a supplier confident in the depth of its catalogue lets you pick the sample. A supplier that insists on curating your twenty is showing you its best twenty.

🎯 How It Works When You License HTML5 Games From a Direct Licensor

Forestry Games has operated since 2017 and licenses a catalogue of 1,049 titles covering HTML5 and Android APK games, with titles also published on Google Play and the Apple App Store. A licence conversation here covers both formats at once, which matters for exactly the reason set out above — an APK is a separate build with separate failure modes, and finding that out after signing a web-only agreement is an expensive discovery. Depending on scope, a licence can include HTML5 builds, APK builds, source where applicable, branding and rebranding rights, and hosting arrangements, alongside distribution and monetization support rather than a file handover and good luck. Because the catalogue is developed in-house as well as licensed, provenance questions have answers. You can buy HTML5 games title by title, or browse the catalogue and scope a bulk licence against your own stratified sample — and you should insist on running that sample before anything is signed, here or anywhere else.

🧸 Licensing Branded Games for Campaigns, Portals and Events

Forestry Games also works with branded IP and has brand partnerships including Disney, Nickelodeon, Cartoon Network and Warner Bros. Businesses can license branded game content through Forestry Games for marketing campaigns, white-label game portals, live events and mobile apps. Branded titles carry approval and compliance requirements that generic catalogue titles do not, so the evaluation protocol above needs one extra column: what the licensor's approval path looks like and how long it takes. The practical next step is to send a scope — territories, platforms, term, formats, and the rough shape of your catalogue need — and ask for build access to a sample you choose. If a white-label portal is the end goal, ask for a demo of one running before you commit to a catalogue size; you can also review licence scope and pricing or look at APK game licensing if Android is in play.

🧭 The Actual Recommendation

Do not try to evaluate a thousand games. Accept that you are running a twenty-title sample, then make that sample do the one job it is statistically good at: proving or disproving that a defect is systemic. Choose the twenty yourself, stratify them across build vintage and engine and control scheme and file weight, test them cold on old hardware, and write the results down as rates rather than impressions. Then close the gap the sample leaves open with an acceptance window, a replacement right and a defect-rate trigger, because those clauses — not more play-testing — are what protect you from the nine hundred and eighty titles you will never open.

If you are about to shortlist suppliers, do the cheap thing first: send each of them the same list of twenty titles you picked yourself and ask for build access. How they answer that email will sort your shortlist faster than the games will.