Users asked for a mobile app. The website was built on WordPress and was heavy with content; a PWA was not a realistic path. The product’s core value — tests and answers — was a good fit for a focused mobile experience.

There was also a distribution hope: Google Play could bring a new acquisition channel.

Problem

Mobile users needed a focused way to practice, without the weight of the full website. The team was small, with no native mobile team. The question was: what is the smallest app that can validate the value, and how do we ship it fast without breaking the existing product?

Evidence

  • Users explicitly asked for an app.
  • Competitor research showed the standard feature set and monetization patterns.
  • The site was overloaded with content; the app could be focused on tests.
  • The existing premium subscription could be reused through access keys.
  • Beta results: 7 sign-ups, 4 active (57%), 215 sessions, D3 retention 50%, 0 crashes, 10 bug reports — mostly content, not app stability.
  • Legacy premium keys: only 10 of 100 active premium users activated app access. Older buyers were less likely to activate; many had already passed their exams and were at sea.

Options considered

  1. Build a PWA. Reuse the web stack, but the experience would still be heavy.
  2. Build a native app. Best experience, but slower and more expensive.
  3. Wait for Google Play. Avoid alternative distribution, but delay learning.
  4. Build a focused MVP and release on alternative Android stores first. Ship fast, validate stability, handle Google Play later.
  5. Build a full-featured app. More scope, more risk, slower feedback.

Decision

I chose the focused MVP:

  • tests, answers, and premium access via key;
  • simple, fast UI;
  • no extra content or social features;
  • release on alternative Android stores first;
  • use the beta to validate stability and content quality, not growth;
  • keep monetization through the existing premium subscription, not a separate app subscription.

Execution

  • Sep 5: competitor research and MVP feature list.
  • Sep 7: development start.
  • Sep 14: content and SMM preparation; editor tasks for SEO/AEO; beta preparation.
  • Sep 21–24: beta with 7 users.
  • Sep 25: release candidate.
  • Sep 28: landing page and release.
  • Sep 30: added to other Android stores; Google Play still pending.
  • Generated keys manually for legacy premium users and handed them to SMM for distribution.

Result

  • MVP shipped in about three weeks.
  • Beta: 0 crashes, D3 retention 50% (n=4), positive feedback on speed and simplicity.
  • 10 of 100 active premium users activated app access.
  • Adoption was concentrated among recent buyers; older buyers often did not need the app because they had already passed their exams.
  • The main constraint was distribution, not the app itself: without Google Play and with .apk friction, the app could not become a growth channel yet.

What I learned

  • Shipping the app was the easy part. Distribution and activation are the product.
  • A small beta is a signal, not statistics. I used it to validate stability, not to claim product-market fit.
  • Legacy users may not need the app at the moment you launch it; timing matters.
  • What I would do differently: solve Google Play distribution before building; instrument activation and retention from day one; define the app’s job-to-be-done (practice on the go) and measure it explicitly.