Marketing for vibe coders: the smallest plan

Building has become fast. With an AI coding assistant, an idea on Friday can be a working app on Sunday. What has not changed is the Monday after: the app is live, and nobody knows it exists.

If you came to building through AI tools, marketing may feel like someone else's job, with its own jargon and its own gurus. It does not have to be. This guide is the smallest routine that works for a solo maker: one hour a week, no budget, and a way to see whether it is doing anything.

The problem is distribution, not the product

When an app gets no users, the instinct is to add features. It is the comfortable move, because building is the part you enjoy and the assistant makes it nearly free.

It rarely helps. An app with five features that nobody has heard of has the same number of users as an app with one. Before the next feature, the question to answer is: how will the next hundred people find this?

Shipping fast is still a real advantage, just not the one it looks like. It lets you respond to what people say within a day. That only matters once people are saying something.

Know who it is for, in one sentence

Marketing advice gets abstract quickly, so here is the only strategic step in this guide. Finish this sentence:

"This is for [a kind of person] who [has this specific problem] and currently [does this instead]."

For example: "This is for freelancers who send invoices as PDFs and currently sign them by printing and scanning."

Everything else follows from it:

• Where to post: wherever those people already talk.
• What to say: the problem, in their words.
• What your home page says first: that sentence, minus the first three words.

If you cannot finish the sentence, talk to five people who might use the app before writing a single post. It is the least glamorous step and it saves the most time.

Make the first screen do its job

Before sending anyone to your app, open it in a private window and look at it as a stranger for ten seconds.

• Does the first line say what it does, in plain words?
• Is there one obvious thing to click?
• Can someone try it without creating an account, or at least see it working?
• Does it look fine on a phone?

AI-built apps often ship with a generic landing page: a gradient, a vague headline, three feature cards. Replace the headline with your one sentence. It is the highest-value edit you will make this month.

Pick two channels, not six

You do not have time to be everywhere, and posting thinly on six platforms does worse than posting properly on two. Choose:

• One community where your users are. A subreddit, a forum, a Discord server, a Facebook group, depending on who they are. This is where customers come from.
• One place where you share the building. X or Bluesky for most makers. This is where feedback and other makers come from.

In the community, you contribute first and mention your app when it is relevant and allowed. Read the rules before posting; on Reddit, each community has its own, on top of Reddit's site-wide rules. The guide on turning a Reddit post into customers covers this in detail.

Let your shipping write your posts

Here is where building fast becomes a marketing advantage. Every time you ship something a user can see, you have a post. You do not need to invent content.

A routine that fits in one hour a week:

1. Tag a release, or at least write three lines about what changed. GitHub can draft release notes from your merged pull requests (its documentation shows how).
2. Pick the one change a user would care about. Not the refactor. Not the dependency update.
3. Show it: a ten-second screen recording or a before and after.
4. Post it in your two places, written differently for each.

If your commit messages are tidy, the sorting is easier. A convention such as Conventional Commits, where a message starts with feat: or fix:, makes it obvious which changes are worth announcing. Your assistant can follow it if you ask.

Shipped this week: [what people can do now, in one line].

[Why: who asked, or what was annoying before.]

[screen recording]

[your tagged link]

upTake automates the middle of this routine. Connected to GitHub, it reads your release notes, pull request titles and commit messages, never your code, sorts each change into feature, improvement, fix or internal, and writes announcement drafts for the first two, each with its own tagged link. You edit and post them yourself. The guide on announcing a feature has templates if you prefer to write them by hand.

Put a tag on every link

This is the one technical habit in the guide, and it is a small one. When you share a link to your app, add a short label to it:

yourapp.com/?ut=x-dark-mode

yourapp.com/?ut=reddit-freelance

The page that loads is the same. The label tells your analytics which post the visitor came from. Without it, a good week is a mystery: visits went up, and you cannot tell which of your four posts did it.

One label per post, lowercase, platform first. That is the whole convention. The guide on UTM links explains the rest, and the link builder writes the address for you.

Look once a week, at three numbers

You do not need a dashboard habit. Once a week, for each post:

1. Visits: did anyone click?
2. Signups: did the page convince them?
3. Payments, if you charge: were they the right people?

Then one decision: what to do more of, and what to stop.

The pattern in that example is common for apps built with AI tools: posts about how it was built attract other builders, who are curious and not customers. They are worth writing for the feedback. They are not your growth.

When you start charging

Connect your payment provider as soon as you have one, so that the weekly look goes all the way to revenue. With Stripe, a restricted read-only key is enough, and nothing changes in your checkout. The guide on Stripe revenue attribution without code explains what you learn that way and how reliable it is.

What to skip for now

A lot of marketing advice is written for companies with teams. For a solo app in its first months, you can leave these alone:

• Paid ads. They need a budget and a conversion rate you do not know yet.
• Search engine optimization as a project. Write a clear page and move on. It pays over months.
• A content calendar. Your releases are your calendar.
• Being on every platform. Two, done properly.
• A rebrand. Nobody is leaving because of your logo.

The routine on one screen

• One sentence: who it is for, what problem, what they do today.
• A first screen that says that sentence.
• Two channels: one where users are, one where you share the building.
• Every week: ship, pick one visible change, show it, post it twice.
• A tag on every link.
• Once a week: visits, signups, payments per post, and one decision.

That is about an hour a week. The assistant does not write this part for you, but it is the part that decides whether anyone uses what you built.