DEV Community: magistral

A signup is not a tester: designing a Google Play closed-test cohort

magistral — Sun, 18 Oct 2026 17:30:50 +0000

A group can have fifteen people and still not be ready to test a single app.

Some have not joined the right test. Some cannot install the build. Others are ready, but their availability starts next week.

The design problem I am working through for Dozena is how to make those differences visible before a shared testing window starts.

Disclosure: I am building Dozena. It is in development, the public site currently collects waitlist registrations, and there is no completed pilot yet. This article describes a proposed design, not production results.

The requirement and the product are different things

For personal developer accounts created after November 13, 2023, Google describes a closed test with at least 12 testers continuously opted in for at least 14 days before applying for production access. Meeting that threshold is not a guarantee of approval. See Google's current testing requirements.

A coordination tool cannot make that decision. It can help participants organize genuine testing and useful feedback.

That means a check-in inside our tool must never be presented as proof of Google Play eligibility.

1. Model an assignment, not just a member

A member record answers “who joined the group?” It does not answer “who is ready to test this particular app?”

I would track one assignment per tester–app pair:

Field	Purpose
Tester and app identifiers	Identify the relationship
Setup status	Separate pending, blocked and ready
Reported opt-in time	Record what the participant reported, with its source
Install status	Surface access or device problems
Feedback and check-ins	Coordinate testing activity, not certify eligibility
Withdrawal or blocker	Make problems visible without silently replacing history

The important distinction is reported versus verified. A participant checking a box is a self-report. The interface should say so.

2. Use a readiness gate before the shared start

The proposed cohort lifecycle is:

Forming → setup → active testing → review → closed

During setup, participants check access, installation and availability. If an app has unresolved installation problems, a full member list should not make its status green.

A practical readiness checklist:

Is the correct test link available?
Can each assigned tester access and install the app?
Are any login instructions available without exposing production credentials?
Does everyone understand the reciprocal commitment?
Are blockers resolved before the planned start?

These are coordination checks, not substitutes for the Play Console.

3. Treat dropouts as events, not erased rows

In a reciprocal group of 15 app owners, each app has 14 possible peer testers if everyone tests every other app. That is a planning margin, not a reliability guarantee.

If someone leaves, retain when they left and which assignments were affected. Adding another person should not make the dashboard pretend the replacement has already completed the previous person's time.

This is why I would avoid a single “testers: 14” counter. More useful labels are assigned, setup ready, blocked, and withdrawn, with the relevant timestamps.

4. Measure the pilot before claiming the model works

The first pilot needs to answer questions a waitlist cannot:

How many registrants actually become setup-ready?
Which installation or access issues delay the start?
How much time does reciprocal testing take each participant?
Where do participants drop out?
Is the private feedback useful to the app owner?

Until those answers exist, synchronized rounds are a hypothesis worth testing—not a proven fix.

Want an invitation when the first round is ready?

If you are preparing an Android closed test and are willing to test other developers' apps too, join the free Dozena waitlist.

The MVP is planned to be free and open source. Registration is for an invitation when the first group is ready; it does not start a round today or guarantee Google Play approval.

12 developers are not 12 testers per app. The small mistake that breaks a Google Play testing group.

magistral — Sun, 18 Oct 2026 02:03:16 +0000

You find 12 Android developers. Everyone agrees to test everyone else's app.

Problem solved?

Each app has 11 other people available to test it. The owner isn't an extra tester.

I got this wrong in an earlier Dozena post. A reader pushed me to explain the dropout math more clearly. Here's the model I'm building now — including where it can fail.

The group size is not the tester count

Assume each developer brings one app and tests every other app:

Developers in the group	Other developers per app	Margin above 12
12	11	Below the minimum
13	12	None
15	14	Two

The formula is simply testers per app = participating developers − 1.

These are potential testers, not confirmed opt-ins. The table only holds if everyone actually joins each relevant test. Fifteen names in a group chat aren't fourteen testers in Play Console.

The calendar matters as much as the headcount

For personal developer accounts created after November 13, 2023, Google's current requirement includes at least 12 testers opted in continuously for 14 days before applying for production access. Meeting that threshold doesn't guarantee approval.

Google's official testing requirements

Consider an app starting with exactly 12 eligible testers:

Day 1: all 12 opt in.
Day 9: one opts out.
Day 9: a new person joins.
Day 14: the newcomer has not accumulated 14 consecutive days.

The replacement hasn't inherited the departing person's history.

That doesn't mean the remaining testers lose their own history. It means this app no longer has the required twelve people with the necessary continuous opt-in history at that point.

Starting with 14 confirmed testers can absorb two opt-outs if the remaining twelve stay continuously opted in. That's a buffer, not a promise that people won't leave.

Attendance still isn't useful feedback

A counter can't tell you whether onboarding makes sense.

One reader suggested asking for the screen name and what the tester expected to happen. That's much more actionable than collecting “looks good” until a text box reaches its character minimum.

For a testing round, I'd want to know:

Which flow did you try?
Where did the result differ from what you expected?
What changed after the developer fixed it?

The aim is to improve the apps, not just exchange names on a list.

Why I'm building Dozena

Dozena is my attempt to organize this into synchronized rounds of 13–16 developers, targeting 15: a shared setup period, the same testing window, check-ins and private feedback.

It's still in development. The public site explains the format and accepts waitlist signups. I haven't completed a real pilot yet. The MVP will be free and open source.

It won't sell testers, ask for public Play Store ratings or promise Google approval.

If your Android app is approaching closed testing, and you're willing to test other developers' apps too, join the Dozena waitlist.

I'm the developer behind it. The math above is useful whether you use Dozena or organize your own group.

I built a private automation marketplace. Now I need 100 signups to make it public.

magistral — Sat, 17 Oct 2026 14:35:35 +0000

A while ago, I built a small microservice for one of the communities I'm part of.

The idea was simple: connect people who need automations with developers who know how to build them.

What started as a small internal project turned into something bigger than I expected.

We've already seen over 10k worth of automation work move through the community, and people have repeatedly asked me the same question:

"Why isn't this available to everyone?"

So I started building Unstuck — a marketplace where automation specialists can showcase their work, and businesses can find the right person to build or fix their workflows.

Think of it as a dedicated marketplace for n8n experts, API integrations, AI agents, and workflow automation.

But before spending months building the full platform, I want to validate whether there's enough interest outside my community.

Here's the challenge: 100 waitlist signups.

If 100 people sign up, I'll move forward with opening the marketplace publicly.

No fake launch numbers. No pretending the platform is already finished. Just a real project, early traction, and a simple validation goal.

Waitlist: unstuck

And I'd genuinely like to know: If you're an automation developer or someone who hires them, would you use a platform like this?

vibecoder em 2026: publica app em 2 horas, o Google pede 12 testers, vibecoder some

magistral — Fri, 16 Oct 2026 00:44:27 +0000

literalmente isso. print da regra oficial anexado kkkkk
buildou o SaaS em uma tarde com IA, deploy no mesmo dia, aí o Play Console fala “prove que 12 pessoas usam isso por 2 semanas” e o cara nunca mais aparece

Google Play: 12 testers. 14 days. 0 friends. 1 existential crisis.

magistral — Thu, 15 Oct 2026 21:02:10 +0000

Google Play turned shipping an app into a multiplayer quest.

12 testers. 14 days. No friends online.

I built Dozena to fix that. Now I need 26 devs before I lose the plot.

Dozema

Google Play really said: bro, do you have 12 friends?

magistral — Tue, 13 Oct 2026 19:06:32 +0000

Dozena — Waitlist

Spent 3 months building an app just to discover the final boss: 12 testers for 14 days.

BRO, I WRITE CODE. I DON'T HAVE 12 FRIENDS WITH ANDROID.

So I'm building Dozena: devs helping devs survive the 12/14 nightmare. 100% free.

15 days. 15 signups. If I fail, the project gets executed.

Join the waitlist

Help me prove that developers can collaborate without needing a social life.

Tenho 16 anos. O Google Play me fez conseguir 12 testadores por 14 dias. Então, estou criando a solução para isso — e ela será open source.

magistral — Tue, 13 Oct 2026 17:55:24 +0000

Lista de espera: Dozena

Então, se você é um dev independente, sabe que precisamos passar por um obstáculo: O KRAI DA REGRA 12/14 KKKKKK. Os caras acham que a gente tem amigos com Android ou uma equipe de testers, sei lá.

Então, se você, assim como eu e vários outros devs, não tem uma equipe de testes nem gente suficiente pra ajudar, eu criei o Dozena.

Ainda não lancei oficialmente, mas já estou usando em testes fechados e o projeto está quase pronto.

A ideia é simples: ajudar devs independentes a se ajudarem mutuamente a superar essa barreira.

Se quiser entrar na lista de espera, fica à vontade. Afinal, o Dozena é movido por interesses mútuos: todo mundo ajuda e todo mundo tem a ganhar.

Mas aqui vai minha meta: se eu não conseguir pelo menos 15 e-mails na lista de espera em 15 dias, vou desistir do projeto.

Quero validar se isso realmente resolve um problema para outros devs antes de continuar investindo meu tempo.

Se você também está passando por essa desgraça, dá uma olhada:

Entrar na lista de espera do Dozena

I'm 16. Google Play made me find 12 testers for 14 days. So I'm building the fix (open source).

magistral — Tue, 13 Oct 2026 16:08:14 +0000

👉 Join the waitlist: https://dozema-nkdq.vercel.app/en

What is Dozena?

A free, open-source platform that puts solo devs in the same room:

12 devs. Each one brings their own app.
14 days. Everyone tests everyone else's app in a synchronized round.
Everyone meets the requirement. You give 12 testers, you get 12 testers.

No middleman. No paid testers. No stranger who disappears on day 3.

How it works

Join the waitlist.
When a round fills up, you're matched with other devs.
You test their apps. They test yours.
14 days later, everyone has completed the cycle.

Honest limits

I'd rather tell you now than let you find out later:

Dozena doesn't promise Google's approval. It helps you meet the testing requirement; the review is still Google's call.
Dozena doesn't host your APK. Your app stays where it is.
It's early. Right now I'm validating: I need 26 devs on the waitlist in ~10 days to run the first pilot (rounds of ~13 devs).
Free, and licensed under AGPL-3.0. Read the code, break it.

Why I'm building this

Every solo dev I know has been stuck on this rule. It doesn't need a company
or a paid service. It needs 12 people willing to help each other.

Your turn

🧪 Join the waitlist if you have an app waiting to ship.
🔍 Tell me what's broken in this model. I read every comment.
⭐ Share it with one dev who's stuck on the 12/14 wall.

I'm 16, I'm just getting started, and this is the first version. 😉

Google Play holds my app hostage until 12 strangers use it for 14 days. So I'm building the swap club.

magistral — Tue, 13 Oct 2026 00:30:12 +0000

🇧🇷 Versão em português nos comentários (vou postar o link assim que sair).

The wall

Personal Google Play accounts created after Nov 13, 2023 cannot publish to production until they run a closed test with a minimum of 12 testers for 14 consecutive days.

Think about what that means if you're solo:

You built an app. Alone.
Now Google requires you to know 12 actual humans who will install it, keep it installed, and use it, for two weeks straight.
Your mom counts as 1. Your secondary email doesn't count. Your dog doesn't have a Google account.

Every solo dev without a network stalls here. Paid services emerged charging $15–25 per app to supply the testers. Swap groups on Reddit/Telegram exist... and most die by day 3 because nobody tracks anything and everyone starts on a different day.

I'm building the alternative: Dozena — a free, open-source (AGPL-3.0) tool that runs synchronized rounds:

~13 devs enter the same round, in the same 14-day window
48h setup: join the round's Google Group and opt in to everyone's apps
14 days: open the other 12 apps on at least 2 distinct days, with check-ins
3 short written feedbacks per person; nobody tests their own app
Public reliability ranking — disappear and you lose priority forever

Why synchronized? Because when your own production access depends on the same window as the 12 people testing your app, show-up is not altruism — it's self-interest. The incentive problem solves itself.

What I refuse to do

No APK hosting (everything through official Play closed-test links)
No "guaranteed approval" claims — Google doesn't offer one to anyone; paid services that say that are selling you a refund policy
No selling testers. Ever. Peers test peers.
No Gmail harvesting: each dev uses their own Google Group

The honest part: it starts as a public bet

Instead of "this will work!", I wrote a kill-switch into the repo's decisions log:

If the waitlist gets fewer than 15 real signups in 10 days, I pivot. Publicly.

Currently: 3 real signups in the first 7 hours, from a single Reddit post, with the funnel measured by my own cookie-less tracking (page_view → CTA click → signup):

Tired of the 12 testers / 14 days rule? I made a free open-source tool for synchronized swap rounds

magistral — Mon, 12 Oct 2026 21:36:40 +0000

If you created a personal Play Console account after Nov 13, 2023, Google requires 12+ testers for 14 consecutive days before you can request production access.

Solo devs get stuck here. That’s why I built Dozena.

~13 devs per synchronized round.
48h setup to join the group and opt in to each other’s tests.
14 days of testing, with 3 short feedback reports per tester.
Public reliability ranking. Ghosting means losing priority.
Free during MVP, open source under AGPL-3.0.

Everyone tests each other, nobody tests their own app. Your reliability matters because everyone depends on the same 14-day window.

I need 26 devs for the first pilot. If fewer than 15 sign up in 10 days, I pivot.

Landing: https://dozema-nkdq.vercel.app/en

Criticism welcome, especially about flaws in this model.