Google Play's '12 testers for 14 days' rule nearly killed my launch — so I built a marketplace to fix it

TL;DR — If you have a personal Google Play developer account, you can't publish your app until 12 testers have been opted into a closed test for 14 continuous days. Finding those testers alone is slow and unreliable, and the "tester farm" shortcuts are a compliance landmine. I built twlvr — a mutual-exchange marketplace where you test other developers' apps and they test yours — to make it a fast, fair, human exchange. This is the story and the build.

The rule nobody warned me about

I finished an Android app. Signed build, store listing, screenshots, the whole thing. I hit publish and Google Play said, essentially: not yet.

Since Google tightened the rules for personal developer accounts, you now have to run a closed test before you're allowed anywhere near production:

• 12 testers opted into your closed track,
• for 14 continuous days,
• with real, ongoing engagement — not 12 names on a list.

That last requirement is the killer. It's not "collect 12 emails." It's "keep 12 real people actively opted in, without a break, for two weeks." If the test lapses, the clock resets.

Why it's harder than it sounds

The first time you read it, 12 people / 14 days sounds trivial. Then you try it.

Most indie developers do not have 12 friends with Android phones who will:

1. install a half-finished app,
2. keep it installed for two weeks, and
3. actually open it now and then so the engagement looks real.

So you do what everyone does: you post in subreddits, Discord servers, Telegram groups, and Play Console tester-swap threads. It's slow, noisy, and worst of all flaky — volunteers drop off around day 2 or 3, which breaks the continuous part and sends you back to the start.

You end up spending more energy recruiting testers than you spent building the feature you want feedback on.

The tempting wrong answer: tester farms

There's a whole grey market of "I'll be your tester, you be mine" and paid tester groups. Some of them are just a spreadsheet of accounts one person controls.

I didn't want to go near that, for two reasons:

• It's against the spirit (and often the letter) of the policy. The point of closed testing is real feedback from real devices. Faking engagement is exactly what Google is trying to screen out, and it puts your production review at risk.
• It's bad for the thing I actually care about — shipping software people use. Twelve bots clicking once a day tell me nothing about my app.

So the constraint became: real humans only, no self-run multi-account farms. That single rule shaped the entire product.

The idea: reciprocity, turned into a marketplace

Here's the insight that made it click: every developer stuck on this rule is also a perfect tester for someone else. We all have the same problem at the same time. That's a classic two-sided market waiting to happen — except both sides are the same people.

So in twlvr, there's no "developer tier" and "tester tier." Every account is both. You post your app that needs testers, and you test other people's apps. A lightweight points economy balances giving and receiving so nobody can only take.

You test other apps        →   you earn points + reputation
You spend points           →   real testers join your closed test
Everyone checks in daily   →   the 14-day streak builds itself

How it works, concretely

1. One account, both roles. Sign up on web or Android — same account, same streak across devices.
2. Post a request. Drop your closed-test opt-in link and how many testers you need.
3. Browse the feed. Apps that need testers, each with the developer's reliability and reputation score.
4. Test and check in. A single daily tap logs continuous testing. You can watch the streak march toward day 14 — which is exactly the signal Play Console wants.
5. Get matched back. Your points and good standing bring real testers to your app.

The stack

Since this is dev.to, here's the part you actually came for. It's a pnpm + Turborepo monorepo:

• Web — Next.js 16 (App Router) with Tamagui, deployed to Cloudflare Workers via @opennextjs/cloudflare. The marketing site (twlvr.de) and the dashboard (app.twlvr.de) ship from the same app.
• Mobile — Expo / React Native (SDK 58), Android-first, built with EAS.
• Backend — Supabase (Postgres, Auth, Storage, Realtime), pinned to the EU region (Frankfurt) because the audience is global and I wanted GDPR to be the default, not an afterthought.
• Shared packages — a framework-free core package holds the actual logic (reputation, points, streak, matching, rotation), with zod schemas shared between web and mobile so validation can't drift.
• Monitoring — Sentry for errors and tracing on both surfaces.
• i18n — 10+ languages, including a right-to-left locale, because closed testing is a worldwide headache.

Keeping the business logic in a pure core package — no React, no network — turned out to be the single best decision. The reputation and points rules are just functions I can unit-test in isolation and reuse identically on web and mobile.

The genuinely hard parts

The CRUD is easy. These were not.

1. Proving "14 continuous days"

Google cares about continuity, so the product has to make continuity cheap. The daily check-in + streak is the whole mechanic: one tap, logged server-side, visualised as a 14-cell streak. Miss a day and you can see the gap — the same way Google will.

2. Matching, without starving anyone

A naive feed ("newest first") means the loudest or earliest posters get all the testers and newcomers starve. Matching has to weigh who needs testers now, who has been reliable, and who has given back, and rotate attention so every honest request gets served.

3. A points economy that can't be gamed

Points are what stop the market collapsing into pure takers. Earn by testing, spend to get tested. The hard design question is pricing: too expensive and new devs can never afford testers; too cheap and people hoard. It's an ongoing balancing act — very much build in public.

4. Reputation & reliability to punish flakiness

This is the anti-farm core. Reliability tracks whether you actually check in on the apps you committed to; reputation is the longer-term signal. Flaky testers lose standing and get matched slower; dependable ones rise. The incentive points one way: show up for real.

5. Real humans only

No self-run multi-account farms — by policy and by design. Testers are matched to developers, consent is explicit, and the whole loop assumes a person on the other end, not a script. It makes growth slower and the product honest. I'll take that trade.

What I'd tell myself at the start

• Model the policy as a feature, not a chore. "14 continuous days" isn't paperwork — it's the core loop. Build the whole UX around making continuity effortless.
• Put logic in a pure package early. Your scoring and economy rules will change weekly. Keep them out of components.
• Pick your data region on day one. Retrofitting GDPR/EU residency is miserable; choosing Frankfurt up front cost nothing.
• Decide your ethics before your growth hacks. "No tester farms" slowed me down and is the reason the product is worth using.

Try it / who's building this

If you're staring at the same closed-test wall right now: twlvr.de — one account, both roles, free to start, no credit card, web and Android.

twlvr is built by ctrlCheese, a small indie studio shipping in public. If you want to follow the build — the points-economy tuning, the matching experiments, the Cloudflare-Workers-plus-Next.js-16 war stories — that's where it happens.

I'd genuinely love feedback from this community on the matching and reputation design. If you've shipped through Google Play's closed-testing requirement, how did you get your 12? Tell me in the comments. 👇