Choose one organic acquisition channel for your app when time is limited

This is for a consumer-app builder with a usable product, limited founder time, and no ad budget. It is not a list of currently open communities or a claim that one social platform works for every app. The consumer-app acquisition guide remains the starting point if you have not defined the user and job.

Brian Balfour argues that products must work within channel rules, rather than expecting channels to adapt to them.[38] His channel-model essay also connects the monetization model with the acquisition cost it can support.[39] Those are useful constraints, not universal channel rankings or a budget formula. The rejection card below is our original applied exercise.

Check whether acquisition is the next task

Can a relevant person reach a useful result with the product today? If the result fails, promotion is not the repair. If first use works but the next legitimate use is unclear, choose a small learning setting rather than treating broad reach as validation.

Define the useful event before choosing the channel. “Exported a usable edit” says more about the job than “clicked a link.” Keep later return and payment as separate questions. Write down what you do not yet know; you do not need a polished analytics system to distinguish a confirmed task completion from a guess.

Reject before you rank

Use these as requirements to investigate, not assertions about where your buyers are:

Record where the audience evidence came from and when. A channel label is not evidence. “Fitness community” does not establish permission to recruit there. Check the current rules of the actual venue before acting; this resource does not authorize promotional posts or provide platform-specific instructions.

Write the real effort bill

Separate setup from recurring work. Include preparing a contribution, finding suitable people, obtaining permission, answering questions, helping with setup, recording observations, and reviewing claims. Add cash costs if any. “Organic” means no paid distribution in this exercise, not costless labor.

Choose a labor cap you can genuinely honor. A low-price app may justify hands-on work to learn, while being unable to support that same effort for every future customer. Mark the test learning or candidate repeatable acquisition so you do not confuse those economics.

Paul Graham's original early-startup essay emphasizes manual recruitment rather than waiting for users to appear.[4] That supports hands-on learning; it does not justify spam, coercive installation, or an assumption that all manual work scales.

Make a test contract before making content

Complete this sentence: “Until [owner-chosen review point], I will contribute [specific useful thing] in [permissioned setting], within [effort cap], and inspect [useful event]. I will stop if [safety, relevance, or workload condition].”

Reject two alternatives explicitly. Otherwise a weak early signal can become an excuse to start every channel at once. At review, choose among: continue unchanged, fix a prerequisite, change the audience, or stop. If there is too little evidence to tell, say so; do not convert an inconclusive test into a growth claim.

Worked case A: a repeated-use tracker needs learning

Illustrative only. Suppose a workout tracker lets someone log a session, but the founder has not established whether the next-session comparison is useful. Assume a small group host has explicitly agreed to a tester invitation; no real group or available access is claimed here.

The chosen route is a permissioned learning group. The contribution is help completing a real logging task with voluntary participants, followed by a question at their next legitimate session. The useful events are first log completion and, separately, use of that log when another session occurs. The founder fills the effort cap and review date before starting.

Reject a “viral AI workout” format because its likely audience may want advice without a logging tool; that mismatch is a hypothesis, not a finding. Hold search content because query evidence and maintenance capacity are missing. Stop wider promotion if the comparison does not help, and route to activation diagnosis. The decision is learning before scale—not that groups always beat video.

Worked case B: an editing tool can demonstrate its job

Illustrative only. Suppose a visual editor has a working upload-to-export path using footage the operator owns. The intended user edits similar footage repeatedly. Assume the founder has relevant audience evidence for a demonstration venue and has checked its rules.

Choose one truthful demo that shows the tedious selection step and the resulting editable output. The next action is to try that task with suitable footage; export completion is distinct from a view. Reject a generic launch to AI enthusiasts because user overlap is unverified. Hold a practitioner partnership because no willing partner exists yet.

Cap recording, review, and response work before the test. Stop promotion if uploads fail or the demonstrated export is unavailable to new users. If viewers arrive but cannot supply footage, revise targeting or the evaluation path before making more clips. No useful completions or sales are asserted in this scenario.

Download the channel rejection card

Download the CSV worksheet, or use the blank plain-text version. Use one row per candidate. Enter evidence, permission, prerequisites, setup and ongoing effort, useful event, stop condition, and rejection reason. The illustrative rows show a choice and rejected options for each case; replace them rather than treating them as recommendations for your app.

Handoff only after the decision

A short-form test with real proof can move to the software demo brief. Contengine may be relevant for repeatable reviewed short-form work after that choice; it is not a way to create permission, audience access, or product value. A conversation, product repair, or no-promotion decision is an equally valid output.

These practitioner principles do not establish channel performance, demand volume, a payback threshold, or a guaranteed number of users. Keep source attribution unknown when it is unknown, and judge learning alongside owner-recorded effort.