Couple Quiz
Couple Quiz — shipping and operating a real consumer product
My own mobile relationship game, from the initial idea and interaction design through Flutter development, backend, monetization and store release to feedback, fixes and ongoing operation.
External links
A game that fits how two people want to play
Couple Quiz is a mobile relationship and partner game. Two people can play together on one phone, or pair two devices online and each use their own phone. Supporting both contexts gives the product flexibility without requiring every mode to have identical internal behavior.
Online play is useful for long-distance relationships, but also for couples who naturally prefer separate phones. The product work connects that everyday choice with question content, interaction design, answer resolution and the experience of returning to a game.
Testing changed the online interaction model
- Decision
- Let both partners answer simultaneously on their own devices, then resolve the result once both answers are available.
- Rationale
- The original online concept had one partner answer first and the second answer afterward. During testing, the second player spent too much time waiting; the interaction felt slower and unnecessarily sequential.
- Trade-offs
- The flow now needs to bring together two independently submitted answers before resolving the result, while allowing each person to answer naturally on their own device.
Testing exposed friction and led to a change in the interaction itself. This was a product decision based on observed experience, without formal research metrics or a statistical validation claim.
The store visual shows the shared-answer result. It illustrates the resolved state, rather than the timing of answer submission on two devices.
One mobile implementation, with small platform differences
The application logic uses one shared Dart/Flutter codebase for Android and iOS. This keeps product behavior in one implementation across the two mobile platforms.
Platform-specific handling is minimal, but still exists where needed. AdMob identifiers and configuration differ between Android and iOS. Sharing the codebase reduces duplication while leaving room for those differences.
A backend sized for the product's workload
- Decision
- Keep the API lightweight with vanilla PHP and MySQL, without a heavyweight backend framework.
- Rationale
- The current product problem can be solved with a simple, operationally inexpensive backend optimized for its workload.
- Trade-offs
- Keeping the framework layer small still requires deliberate optimization and implementation discipline.
The lightweight PHP/MySQL backend is optimized for the product's workload and has demonstrated throughput in the hundreds of requests per second. This is a workload observation, not a guaranteed service level or a formally certified benchmark.
Push notifications reconnect players with the game
Firebase delivers push notifications for events such as a new game, a player's turn and other relevant game-state changes. Its role here is notification delivery; the product backend and database are PHP and MySQL.
Notifications are part of operating the game flows beyond the screen currently open on a phone. They sit alongside the online interaction rather than defining its entire backend architecture.
Three distinct ways to access question content
The model allows meaningful free play and several paths to additional content. A temporary rewarded unlock, a permanent category purchase and Premium have different scopes.
- Free: the basic/default question pack, banner ads and a fullscreen/interstitial ad before results. For a rewarded unlock, a random locked pack is selected; after watching the rewarded ad, that pack becomes available for 3 hours.
- Single pack: a one-time purchase permanently unlocks one specific category for lifetime access and removes ads within that purchased category. Ads elsewhere are unaffected.
- Premium: a subscription unlocks all question packs and removes advertising globally. It is separate from a one-time category purchase.
Purchases and advertising have different responsibilities
RevenueCat handles purchases and subscription entitlements, including the Premium lifecycle and cross-platform purchase state. The public story stays at that responsibility rather than detailing private product configuration.
AdMob provides banners, fullscreen/interstitial advertising before results and rewarded ads for the temporary random-pack unlock. Platform-specific configuration supports Android and iOS. The different access paths are a product choice; no conversion or monetization optimization metrics are claimed.
The store visual presents the question categories. Choosing a category in the product is distinct from the random locked pack selected for a rewarded temporary unlock.
Release connected the implementation to a live product
Couple Quiz is published on the App Store and Google Play, with a public product website. Store delivery is part of the same ownership as the interaction design, shared mobile implementation, API, purchase entitlements and notifications.
The product has real users and paying subscribers. Release made maintenance and feedback part of the ongoing work, rather than ending the project at a completed application build.
A translated interface was not enough
After adding more languages, the UI switched correctly to some of them while backend content still arrived in English. Testing had focused mainly on Czech and English, where both parts behaved correctly, so the mismatch was not visible in those checks.
A report through the in-app feedback form exposed the production issue. Diagnosis traced it to the mobile language enum/configuration: it had not been extended for the added languages, so backend requests fell back to English behavior.
I corrected the mobile language configuration and released an application update. The lesson is that translated UI, mobile configuration, backend language handling and returned content must agree end to end. Real user feedback can reveal combinations that internal testing did not cover.
Feedback became a production update
Conceptual sequence of the localization fix, not an internal system architecture or a response-time measurement.
- In-app feedback
- Diagnose the language mismatch
- Correct mobile language configuration
- Release an app update
- Continue product operation
Shipping is one step in owning the product
Couple Quiz is live on iOS and Android and actively operated for real users, including paying subscribers. Fixes and improvements continue based on production feedback.
End-to-end ownership means connecting the initial idea, product decisions, mobile and backend implementation, monetization and release with what happens afterward. The simultaneous-answer change and localization fix are concrete examples of changing the product when experience reveals a better next step.