25 May 2026 - 5 min read
On 25 May 2026, Riddle Quest had one of those useful product days where the visible app did not simply get "more features". Instead, the work moved the project closer to being something that can survive release pressure: easier to test, clearer to operate, safer around rewards, and less dependent on memory.
Release Work Is Product Work
It is tempting to treat release readiness as a checklist that happens after the product is built. In practice, it is part of the product.
For a mobile game, the risky parts are not only the game board or the animations. They are also the quiet edges:
- What happens when a modal appears on a foldable?
- Can the app still open a support handoff after a provider-auth session?
- Does a rewarded ad grant coins once, and only once?
- Can a future developer run the right Android matrix command without spelunking through old notes?
- Are docs close enough to the codebase that they remain useful?
The 25 May updates were mostly about those edges. They turned several "we should check this manually" areas into named, repeatable surfaces.
Making QA Addressable
One of the most important changes was the QA surface harness. Instead of treating screenshots as a loose manual activity, the app now has a catalogue of pages, modals, variants, and popups that can be opened directly.
That matters because visual QA usually breaks down in two places. First, the state is hard to reach. Second, once you reach it, nobody is quite sure whether the screenshot proved the right thing.
The new QA inventory gives each surface an ID, a renderer, and expected text checks. The Android matrix coverage script now verifies that the surface list, renderer map, expected text checks, and modal registry stay aligned. A local check passed with 51 QA surfaces across 8 configured Android virtual devices.
That is a big shift in confidence. It means release QA is less dependent on a person remembering every modal path and more dependent on source-controlled definitions.
The useful pattern is simple:
- Give every important UI state a stable name.
- Make it directly reachable.
- Assert that it renders the functional text or control that matters.
- Run it across the device classes that represent real risk.
- Fail loudly when a new surface is added without coverage.
That is not just testing. It is product maintainability.
Moving Rewards To A Safer Boundary
Rewarded ads also became more production-shaped.
The project standardised the rewarded-ad implementation around Google AdMob / Google Mobile Ads, with documentation updated to match. On the client, RewardedAdService now handles mobile ads initialisation, readiness subscriptions, retry behaviour, reward confirmation, and listener cleanup.
The more important boundary is on the backend. The Firebase callable awardedAdCallback records completed rewarded ads, checks the authenticated user, validates the placement, applies cooldown behaviour, and uses a transaction so a callback can be processed idempotently.
That is the right split for a coin economy. The client can show the ad and react to the result, but the server should decide whether the reward is valid and what the new coin balance is.
For a game, this is the difference between "the UI seemed to work" and "the economy has a defensible source of truth".
Reducing Drag Around The Codebase
A lot of the day was also codebase hygiene, but not the cosmetic kind.
Docs were moved into docs/, package scripts were documented in readme.md, stale rewarded-ad provider notes were removed, and the Android matrix scripts became easier to run and verify. The project also went through a Prettier pass, which is easy to dismiss until you need to review a risky diff quickly.
The same theme showed up in the auth surface. The custom auth area was pared back and normalised so it was less of a sprawling release burden, while still leaving the app with concrete QA routes for login, sign-up, password reset, and related states.
This kind of cleanup pays back when the next issue arrives. If the command is documented, the files live where expected, and the surface can be opened by ID, the team spends less time reconstructing context and more time fixing the real problem.
The Takeaway
The best release-readiness work turns uncertainty into a system.
For Riddle Quest, 25 May was about making the app easier to prove: UI states became addressable, rewarded ads moved towards a safer server-authoritative flow, docs got closer to the working commands, and the Android matrix gained stronger coverage checks.
The decision rule I would keep from this pass is:
If a release risk is important enough to check twice, it is important enough to name, automate, and document.
That is how a product stops depending on heroic memory and starts depending on repeatable evidence.