Dev Diary
MyRin and CivicPass shipped within a year of each other. Here is what we got wrong, what we got right, and what we would change if we were starting today.
Shipping two apps in twelve months was not a plan. It was the result of one app - MyRin - taking longer than expected to reach a state we were comfortable shipping, and a second idea - CivicPass - being clearer in scope and faster to execute. We ended up launching both within a year of each other. The experience was instructive in ways that a single launch could not have been.
This is the honest version: what broke, what worked, and what we would do differently.
MyRin's original design was simpler than what shipped. The first version had 50 levels. Then we built another 50 because the earlier ones felt too easy. Then we rebuilt the first 30 because the design language had evolved. Then we added difficulty categorization. Then accessibility improvements. By the time MyRin shipped, it had 1000+ levels and a design system we were genuinely proud of.
The lesson is not that scope creep is wrong - the product is better for it. The lesson is that scope creep without a forcing function has no natural endpoint. We could have expanded MyRin's level count indefinitely. What finally forced the launch was a deliberate decision to stop adding and ship what we had.
CivicPass had a harder constraint: the mock question pool for citizenship exams is defined and finite. The scope was bounded by the source material. That external constraint was liberating - we knew we were done when we had covered the mock content. We would build scope constraints into future products earlier rather than letting the creative process define the perimeter.
MyRin and CivicPass have almost no audience overlap. MyRin players are motivated by cognitive challenge and enjoyment. CivicPass users are motivated by a specific legal deadline - their naturalization interview. These are completely different purchase psychologies.
For MyRin, the distribution question is discoverability: how do people find a logic puzzle game among thousands of similar apps? The answer is App Store Optimization, content marketing (like the blog you are reading), and social proof. Reviews and word of mouth matter disproportionately.
For CivicPass, discoverability is different: people searching for citizenship exam preparation are already motivated. The question is not getting their attention but earning their trust. Is the question bank mock? Is it up to date? Does offline mode actually work? These are the questions the product page and onboarding must answer before the download decision is made.
We underestimated how different these distribution needs were and spent the first few months after each launch applying lessons from the wrong product to the other one. Each app needed its own growth model from the beginning.
CivicPass was built offline-first from day one - the full question bank is available without internet access from the first launch. This was a deliberate architectural decision based on a simple user insight: people preparing for citizenship exams study in places without reliable internet. Commutes, waiting rooms, lunch breaks. A preparation app that requires a connection adds friction at exactly the moments when study sessions happen.
We initially had MyRin requiring a connection for some features. Player feedback was clear: the most common session contexts - bedtime, commutes, travel - were often low-connectivity environments. We moved MyRin to fully offline playback for all 1000+ levels before the first major update. The session completion rate improved measurably after that change.
If your app's core value can be delivered offline, deliver it offline. The infrastructure cost is real but the user benefit is larger than any engagement metric suggests, because offline capability enables the sessions that engagement metrics never see.
Both MyRin and CivicPass serve multilingual audiences. MyRin has French and Arabic localization. CivicPass covers French citizenship exam content and serves French, English, and Arabic speakers.
The i18n architecture for both apps was built with React Native's i18next integration from the start. Adding a new language is a translation task, not a development task. We could not have built this in later without significant refactoring; building it in from day one cost perhaps 15% more initial development time and saved multiples of that when the first localization landed.
For any app targeting a multilingual audience: build the i18n layer before you build any UI strings. If you are not sure whether you will need multiple languages, build it anyway. The cost of adding it after the fact is always higher than the cost of not needing it.
We spent a small amount on paid acquisition after MyRin launched. The installs came while the spend was active and stopped when it stopped. The math did not work at the early-stage scale we were operating at.
The blog - posts like the ones on MyRin's cognitive approach and the CivicPass citizenship exam guides - produces a different curve. A well-optimized article ranking for a relevant search query drives installs for months and years without ongoing spend. The production cost is fixed; the return compounds with time.
We started the content program too late. If we were starting today, the blog and pillar page SEO strategy would be running in parallel with development - not as an afterthought after launch.
Early users of both apps sent feedback that was unusually specific and actionable. They had chosen to install the app deliberately, they were engaged enough to reach out, and they had a clear comparison point: the experience they expected versus the experience they got.
The patterns in that early feedback pointed directly at the highest-leverage improvements. For MyRin: difficulty calibration in the first 20 levels was too steep for new players. For CivicPass: the French exam content needed better topic tagging so users could drill weak areas specifically. Both of those changes shipped within the first 60 days and had measurable impact on retention.
Read your early reviews obsessively. Reply to them. The signal quality decays as the app scales - later reviews are more diverse, less representative, and harder to act on. The first 100 reviews are your most valuable product research.
Fewer things changed fundamentally than we expected. The core products are what we intended them to be. What we would change:
The things we got right: offline-first architecture, internationalization built in from the start, and the decision to write every line of the question bank from official sources rather than scraping or adapting third-party content. Those decisions have not created any problems. The other decisions have.