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

This is for a consumer-app builder with a working product, limited founder time, and no ad budget. It is not a list of communities that are open right now, and it does not claim one social platform works for every app. If you have not yet defined your user and the job your app does for them, start with the consumer-app acquisition guide.

Brian Balfour argues that a product has to work within a channel's rules, rather than expecting the channel to bend to the product.[38] His channel-model essay also ties the way you make money to the acquisition cost you can afford.[39] Treat these as useful limits, not channel rankings or a budget formula. The rejection card below is our own exercise, built on those ideas.

Check whether acquisition is the next task

Can a person who fits your audience reach a useful result with the app today? If not, promotion will not fix that. If first use works but the next use is unclear, choose a small group to learn from, not broad reach.

Define the useful event before you choose a channel. "Exported a clip they can use" tells you more about the job than "clicked a link." Keep return visits and payment as separate questions. Write down what you do not know yet. You do not need a polished analytics setup to tell a confirmed task from a guess.

Reject before you rank

Use this table as a list of things to check, not as claims about where your users spend time:

Record where each piece of audience evidence came from and when you found it. A channel name is not evidence. "Fitness community" does not tell you that you may recruit there. Check the current rules of the exact place before you act. This guide does not approve promotional posts.

Write the real effort bill

Split setup from recurring work. Count the time to prepare what you will share, find suitable people, get permission, answer questions, help with setup, note what you learn, and check your claims. Add any cash costs. In this exercise, "organic" means no paid distribution. It does not mean free labor.

Pick a time cap you will really keep. A low-priced app may justify hands-on help while you learn, yet you may not be able to give every future customer that much help. Label the test either learning or candidate repeatable acquisition, so you do not mix up the two.

Paul Graham's early-startup essay says to recruit users by hand rather than wait for them to show up.[4] That supports hands-on learning. It does not justify spam, pushing people to install, or assuming all manual work can scale.

Make a test contract before making content

Fill in this sentence: "Until [review date you choose], I will share [one specific useful thing] in [a place where I have permission], spend no more than [time cap], and watch [the useful event]. I will stop if [a safety, relevance, or workload problem happens]."

Name two options you are rejecting. Otherwise a weak early signal becomes an excuse to start every channel at once. At the review, pick one: continue as is, fix something that was missing, change the audience, or stop. If you have too little evidence to tell, say so. Do not turn an unclear test into a growth claim.

Worked case A: a repeated-use tracker needs learning

Illustrative only. Say a workout tracker lets people log a session, but the founder has not found out whether the "compare with last session" view is useful. Assume a small group's host has agreed to a tester invitation. No real group or access is claimed here.

The chosen route is a permissioned learning group. The founder helps volunteers finish a real logging task, then asks one question at their next real session. The useful events are the first completed log and, separately, use of that log at a later session. The founder fills in the time cap and review date before starting.

Reject a "viral AI workout" video format. Its likely audience may want advice, not a logging tool, though that mismatch is a guess, not a finding. Hold search content, because the search evidence and the time to maintain it are missing. If the comparison view does not help, stop wider promotion and go to activation diagnosis. The lesson is to learn before you scale, not that groups always beat video.

Worked case B: an editing tool can demonstrate its job

Illustrative only. Say a video editor has a working path from upload to export, using footage the maker owns. The intended user edits similar footage again and again. Assume the founder has audience evidence for one demo venue and has read its rules.

The founder picks one honest demo. It shows the slow step of picking clips and the editable result. The next step is to try that task with suitable footage. A finished export counts as a result, and a view does not. Reject a general launch to AI fans, because nobody has checked how much they overlap with real users. Hold a practitioner partnership, because no willing partner exists yet.

Cap the time for recording, review, and replying before the test starts. Stop promotion if uploads fail, or if new users cannot reach the export shown in the demo. If viewers arrive but cannot supply footage, change the targeting or the trial path before making more clips. This scenario claims no real completions or sales.

Download the channel rejection card

Download the CSV worksheet, or use the blank plain-text version. Use one row per candidate. Enter the evidence, permission, prerequisites, setup and ongoing effort, useful event, stop condition, and reason for rejecting. The illustrative rows show one choice and the rejected options for each case. Replace them with your own, and do not treat them as advice for your app.

Handoff only after the decision

Short-form helps most when your app solves a problem people recognize in seconds, and your chosen audience already watches that kind of video. It helps less when the only proof is a vague promise or attention from the wrong viewers. With real proof to show, use the software demo brief. LaunchMax makes both: screen demos that show your app at work, and UGC-style videos where a realistic AI creator talks about it on camera (the problem, a reaction, the outcome). It posts them to your own accounts after you approve each one. It cannot create permission, audience access, or product value. Talking to users, fixing the product, or choosing no promotion are equally valid results.

These ideas do not tell you how any channel performs, how much demand exists, when an acquisition cost pays back, or how many users to expect. If you do not know where a user came from, write "unknown."