How to Market an App: The Solo Developer's Playbook

You shipped it. The build is through review, the product page is live, and the installs graph is a flat line with three points on it, two of which are you. Now you have to figure out how to market an app while also being the person who fixes the crash reported this morning.

Almost every guide for this is written for a team with a media budget, an attribution vendor, and someone whose whole job is growth. You have none of those. What you have is a few hours a week that could otherwise go into the product. So the useful question is not "what are the channels" — it is what order to do things in, and what to skip. That is what this playbook is.

What you'll need before any of this works

An app that is live or in review. Marketing a thing that does not exist yet costs you the launch, because the interest arrives before the download button does.

App Store Connect access. Most of the first day's work happens there and costs nothing.

A way to reach five real users. A TestFlight group, a Discord, five people who replied to a post. Five is enough to tell you whether the product works.

Four hours a week you will actually protect. Not "as much as I can" — a fixed slot, because everything here compounds and nothing here works once.

What you do not need: an ad budget, a mobile measurement partner, a landing page with a hero video, or a content calendar. Those come later, if at all.

The short version

Write one sentence naming who the app is for. Check that your existing users come back. Rewrite the App Store product page — keywords, screenshots, preview video. Produce the assets once, properly. Pick two channels and ignore the rest. Launch on a chosen date. Then watch two numbers.

Step 1: Write down who the app is for, in one sentence

Do this before anything else, because every step below reuses the sentence verbatim. The format is boring on purpose:

<App> helps <a specific person> <do a specific thing> without <the annoying part>.

Not "for everyone who takes notes." For "for iOS developers who need to file a bug with a video attached." The narrower version does two jobs at once. It tells you which subreddit, forum, and Slack are worth your four hours, and it hands you the exact words for the App Store subtitle and the first screenshot caption.

The test is whether a stranger can repeat it back after reading it once. If they cannot, you will spend the next month explaining your app instead of distributing it. Rewrite until they can, then paste that sentence into a file and stop editing it.

Step 2: Check that the users you already have come back

Before you work a single channel, open App Store Connect, go to App Analytics, and look at the retention chart for the users you already have. If people install and never return on day three, every hour you spend on acquisition buys you a slightly faster leak.

With three digits' worth of users the chart is noisy and you should read it as a direction, not a measurement. That is still enough. A curve that drops to nothing by day three and a curve that flattens out above zero look different long before either is statistically respectable.

This is the step that separates a marketing problem from a product problem, and they need opposite responses. If retention is flat, the fix is in the app, and the cheapest way to find it is to message five of those users and ask what they opened it for. If retention holds, you have something worth pushing and the rest of this playbook is worth your time.

Downloads are a lagging indicator of a product people come back to. Fixing the first is easy and temporary; fixing the second is the actual work.

Nobody wants this step. It delays the fun part and it can tell you something you would rather not hear. Do it anyway — it is the only step here that can save you a month.

Step 3: Spend the first hours on your App Store product page

This is the highest-return work available to one person, and it is free. The product page is where a searcher already looking for your category decides, and unlike every channel below it, Apple publishes the exact limits you are working inside.

Per Apple's Product Page documentation (checked 6 August 2026), you get up to 10 screenshots, up to three app previews of up to 30 seconds each, and a keyword field limited to 100 characters total.

The keyword field is the highest-return 100 characters you will write

Those 100 characters are separated by commas with no spaces — Apple is explicit about that, and the spaces you leave in are characters you paid for and cannot use. Do not repeat words already in your app name or subtitle; the store already indexes those. Do not put in your competitor's brand name. Spend the whole budget on terms a person would actually type.

bug,report,screen,record,video,capture,simulator,ios,dev,tester,qa,feedback,repro,triage

That example is 88 characters. Count yours before you paste it, then leave the field alone for a few weeks — you cannot learn anything from a variable you change every day.

The first two screenshots are the ad

Most people never swipe. The first two screenshots have to state what the app does and who it is for, using the sentence from Step 1, and they have to be legible at the size the search results actually render them — which is small. Set your phone at arm's length and look at your own listing. If you cannot read the caption, the caption is decoration.

Step 4: Make the assets once, properly

Here is the part every other guide skips with the phrase "use compelling visuals." Producing the screenshots and the preview video is where a solo launch actually loses a week, and it loses it in the same three places every time.

The screenshots. Ten slots; use four to six. Each one carries a caption that finishes the sentence "this app lets you…". Frame real screens, not marketing collage — a reader who downloads and sees something different than the store showed them churns immediately and sometimes says so in a review.

The app preview video. One is enough. Thirty seconds is the ceiling and you should be under it. It is the highest-conversion asset on the page and the one most often skipped, because making it is the annoying part: capture a clean run, trim it, add motion, add captions, export at the right size, upload, repeat when the UI changes.

Everything you will reuse. The same footage becomes the launch post's clip, the reply-to-a-question clip, and the thing you paste when someone asks what you built. Making it once and re-cutting is cheap. Making a new one per channel is how the week disappears.

The honest sequencing rule here: budget a full day for assets and treat it as one task, not as a thing you sprinkle across a week. If you have never done it, what an AI app demo video generator actually does is a reasonable place to understand what the automated end of that spectrum removes and what it does not.

The preview video is not a nice-to-have you get to after the channels. It is the artifact every channel below consumes, which makes it a dependency, not a bonus.

Step 5: Pick two channels where your users already are

Nine channels at ten percent effort each produce nothing, and the phase-based listicles that recommend all nine are written for teams that can staff them. Pick two. Run them for eight weeks before you judge either.

Choose by answering one question: where does the person in your Step 1 sentence already spend attention, without being sold to? For developer tools that is usually a niche forum, a subreddit, or a Discord. For consumer apps it is more often short video, because the app itself demos well in fifteen seconds.

The high-trust, low-reach channel. A specific subreddit, a Slack, a small newsletter's comment section. Slow, and the people who arrive actually use the app. Post to help, answer questions that have nothing to do with your product, and mention what you built only when it is the answer.

The broad, low-trust channel. Short-form video, a general launch site, an aggregator. Fast, spiky, and mostly forgetful. Worth exactly one of your two slots, never both.

The channel you inherit. If you already have a mailing list, a following, or an existing app with users, that is not a third channel — it is a free first one, and it beats both of the above on the day you use it.

The rule that keeps this cheap: give three times before you take once. It is not a moral position, it is how you avoid being the person whose only posts are announcements, in a place that bans them.

Step 6: Launch on a date, with the mechanics Apple already gives you

A launch is a coordination trick: it concentrates a month of scattered attention into one day so that the day looks like momentum. Pick a date at least two weeks out and work backwards.

Apple's own promotion tools carry most of what you need, and all of them are free (checked 6 August 2026):

1. Pre-orders, available 2 to 180 days before release, so the day-one number is not zero.
2. Promo codes — up to 100 per app version per platform, plus up to 100 per in-app purchase. These are what you send to writers, testers, and the people who helped.
3. The Marketing Assets Generator and App Store Marketing Tools in App Store Connect: short links, embeddable product pages, QR codes, and official App Store badges. Use the real badge; a hand-made one reads as unofficial.
4. Apple Ads, available in 91 countries and regions, with a $100 USD credit for new eligible developers. That credit is a free experiment on your own brand and category terms, not a growth strategy.

If you post to a launch site like Product Hunt, the asset that matters is the video, not the copy. A Product Hunt launch video is the app preview from Step 4 re-cut to autoplay silently and make sense with no sound, which is why creating demo videos once and re-cutting them beats making one per surface. Line up the five people who will actually comment before you post; a launch page with no discussion converts worse than no launch page.

Step 7: Watch two numbers, not twenty

Analytics for a solo developer should fit on one screen and take five minutes a week. Two numbers earn that time.

Product page views to installs. This is your conversion rate, it is reported in App Store Connect, and it is the only number that responds directly to the work in Steps 3 and 4. When it moves, the page changed. When it does not, the page did not.

Day-7 retention. This tells you whether more traffic is worth buying. It is also the number that quietly decides whether any of this compounds.

Everything else — impressions, sessions, crash-free rate, follower counts — is worth reading, but not acting on weekly. Impressions in particular go up when you post more and mean nothing on their own.

If you want to change the page deliberately rather than by intuition, Apple's Product Page Optimization lets you run a test with up to three treatments against your current page (checked 6 August 2026). Change one thing per test — the icon, or the first screenshot, or the preview — because a test where you changed three things teaches you nothing about which one worked.

Where this goes wrong

Five failure modes, in the order they usually happen:

Marketing before retention. Covered above and still the most common. You get a spike, the spike leaves, and you conclude the channel does not work when the product was the variable.

Running nine channels at ten percent. Every one of them is under the threshold where anything happens, and you cannot tell which was worth it because none of them got a real run.

The screenshot rewrite loop. Changing the store page every few days feels productive and destroys your ability to attribute anything. Ship a version, leave it up for weeks, then change one element.

Treating the launch day as the finish line. The day produces a spike and a list of people who noticed. What produces installs in month three is the boring version: the same two channels, still running, in week nine.

Buying installs to fix a conversion problem. If your product page converts badly, paid traffic converts badly too — you have just made it expensive to find that out.

The uncomfortable pattern in all five: they are ways of being busy that feel like marketing. The playbook above is mostly a defence against them.

Doing the video part without losing a week

One section, because the video is one step and not the whole job — but it is the step most likely to stall a solo launch, and it is the step tools genuinely help with.

There are three inputs a tool can take, and the input decides the ceiling. Screenshots animated into a slideshow are the fastest and never show your app moving. A screen recording you already made works with any stack, but you had to get a clean take, and you re-take it every time the UI changes. The third option is a tool that produces the footage itself.

Reely is a Mac app plus an agent skill that takes all three. On the third rung, the agent rebuilds the feature as a working SwiftUI mock, drives it in the Simulator, and films it. The mechanical consequence is the part worth knowing: because the agent authored the run, reely run writes a timeline.json sidecar of labeled interaction marks beside the recording, and the composition references those labels instead of timestamps. Cuts, camera moves, and captions land on the tap rather than near it. Re-record after a UI change and they move with it.

reely run --spec create-project.flowspec.json \
  --device "iPhone 16 Pro" --output out/create-project.mp4

The reel itself is JSON — a FlowSpec and a CompositionSpec — so it is diffable, re-runnable, and editable by the agent that wrote it. The spec format and the CLI are documented if you want to see what that looks like before installing anything.

The limits, plainly. It covers Apple platforms only: no Android, no web apps. Uploaded footage has no sidecar, so on the screenshot and screen-recording rungs you still time cuts by eye. It is free to create and you pay to export. And if you already own a manual recorder and enjoy the editing, you do not need it — how it compares to a manual recorder like Screen Studio is the honest version of that comparison.

Frequently asked questions

How do I promote my app with no budget?

Start with the surfaces that cost time instead of money: the App Store keyword field, screenshots, and one preview video, all of which are free to change. Then pick two communities where your users already are and participate for eight weeks. Apple also gives new eligible developers a $100 Apple Ads credit, which is the cheapest paid experiment available.

How much does it cost to market an app?

It can cost nothing but hours, and for a first app it usually should. The unavoidable cost is the Apple Developer Program membership, which Apple lists at $99 annually as of August 2026, plus whatever you spend making assets. Paid acquisition is optional and should stay optional until your product page converts and day-7 retention holds, because ads amplify whatever those two numbers already say.

How long does app marketing take before it works?

Plan in eight-week blocks, not days. A launch day produces a spike that decays within a week; the channels that compound — a community you post in, a store page that ranks for its keywords — take a month or two to show a trend you can read. If you judge a channel after one post, you will quit every channel.

Do I need ads to get downloads?

No. Ads buy traffic; they do not create the reasons someone installs. Organic search inside the App Store, communities, and referrals all work without spend, and they are what your ads would be amplifying anyway. The sensible order is to make the page convert, prove retention, then spend — starting with the free Apple Ads credit on your own brand terms.

What to do this week

Pick the four hours. Spend the first one writing the sentence from Step 1 and checking your retention. Spend the rest rewriting the keyword field and the first two screenshots, because that is the only work here that pays whether or not anyone reads your launch post.

Then book the day for the assets. If the video is the thing that has been blocking you for three weeks, download it for Mac and get the first cut out of the way — then get back to the part of this playbook that actually needs you.