How Tapzens decides which games to publish
Behind the scenes · 5 min read
The actual pipeline a game goes through here before it appears in the catalogue — what we test, what we scan for, and what gets rejected.
Most game portals are silent about how a game ends up on them, which makes “hand-picked” meaningless. So here is the concrete process a package goes through on Tapzens, including the automated checks that run every time the site is built.
Nothing on this site is user-uploaded, and there is no submission form that dumps straight onto a page. A game is added only after it works on a phone, plays reasonably on a desktop, and passes the tracker scan described below.
1. It has to load on a phone, from cold, quickly
The first filter is size and startup behaviour. Our builds range from about 5 MB to 60 MB on disk, and the ones at the top of that range take noticeably longer on a mobile connection. A game that shows a blank screen for many seconds, or that assumes a mouse hover state exists, is rejected — on a phone the hover state never happens, and games designed around it are unplayable.
2. Orientation is a design decision we do not override
Each game declares whether it is portrait or landscape, and we keep that. Portrait games are thumb-designed vertical puzzles and shooters; landscape games are the wide battlefields — Tank Era, Ace Strike, Arrow Maze Solve and Shift Dash Reac. We do not letterbox a landscape game into a portrait frame to make the site look uniform, because it makes the game worse.
3. A tracker and ad-tag scan runs at build time
The site generator scans every delivered code file and reports analytics and advertising identifiers it finds, separated into what actually loads in a browser versus what is only reachable inside a native app wrapper. This is not decoration — running the audit on the current catalogue reads 361 code files and reports ten distinct ad or tracking identifiers, of which one loads on the web.
That number is the practical reason the audit exists. Game bundles in this category were originally built for mobile app stores and carry their ad-network configuration in the code. It sits inert in a browser build, but we want to know it is there rather than assume it is not. When a page-level Google Analytics tag turned up inside six game entries during a recent build, that is exactly what surfaced it, and those tags were removed so that no analytics run outside the consent prompt.
4. Structured data describes what is really on the page
Every detail page publishes VideoGame, HowTo, BreadcrumbList and FAQPage markup. What it does not publish is ratings or review counts, because we do not collect real user ratings and an invented number in structured data is worse for a player than no number at all. The same reasoning is why the catalogue carries no play counts: a static site with no backend has no way to know how many people played something, and there is no honest figure to print.
5. What gets rejected
Games we cannot get to run cleanly on a phone. Games that ask for a login before the first level. Games whose only content is an ad wall. And games we have no right to distribute — publishing someone else’s work without permission hurts the developer and gets the site removed.
The honest limitation of this process is scale: with 18 games, we are a small curated shelf, not a portal. Every entry has a written guide on the site and every guide was written after reading what that build actually contains. A larger catalogue of the same quality would be better; a bigger number of the same games we already have would not.
If you want to suggest a game, or think one of ours is misfiled, the contact page is a real mailbox that a person reads. That is a smaller promise than “millions of games”, and it is the one we can keep.