Developer Marketing for Founders: A Weekly Cadence a Small Team Can Sustain

You built the thing. It works. You posted it once, got a few stars and some polite silence, and now you are back to writing code because code at least compiles.

That is the normal outcome of marketing in bursts. Developer marketing for founders works when it is boring and regular: a small amount of useful output every week, aimed at the places your users already read, written the way engineers write to each other. This guide gives you a cadence you can run in about four hours a week, the norms of the main channels, and a checklist to start Monday.

Why most founder-led developer marketing stalls

Three patterns show up again and again:

• Big-bang launches with nothing after. One launch post, then nothing for two months. Whatever attention you got has nowhere to go.
• Writing about the company instead of the problem. "We're excited to announce" posts get skipped. "How we cut cold starts from 4s to 300ms" posts get read.
• Posting everywhere once. Every community has its own norms. Showing up only to promote reads as spam, and moderators treat it that way.

The fix is not more effort. It is a smaller, repeatable unit of work and a clear sense of where each piece goes.

The default: one useful artifact per week

Your weekly unit is one artifact that a developer could use without buying anything. Everything else in the week is distribution and conversation around that artifact.

Good artifacts, roughly in order of how well they tend to work for small devtool teams:

Default to the working example. It is the cheapest thing that proves your product does something real, and it doubles as docs.

Bad vs. good

Bad: "Introducing Relaywire: the modern way to handle webhooks."

Good: "Retrying webhooks without double-charging: idempotency keys in 30 lines of Node."

The good version names a problem, a constraint, and a language. A developer knows in one line whether it is for them.

The weekly cadence

This assumes one founder owns it and an engineer contributes once a month. Adjust the days; keep the order.

Monday: pick the topic (30 minutes)

Pull from three sources:

1. Support questions and GitHub issues from last week. If two people asked, a hundred wondered.
2. Things you built or fixed that were harder than expected.
3. Questions you see in communities where your users hang out.

Write the title first. If you cannot write a specific title, the topic is not ready.

Tuesday and Wednesday: write and ship the artifact (2 hours)

• Lead with the code or the result. Put context after.
• Every snippet runs. Test it from a clean environment.
• One call to action at the end: try the quickstart, star the repo, or read the docs page that goes deeper. Pick one.
• Publish on your own domain first. You own that URL forever; you do not own anyone's feed.

Thursday: distribute with the channel's norms (1 hour)

Post to one or two channels, not six. Adapt the framing to each (see below). Then stay around to answer comments. A reply from the person who built the thing is often worth more than the post.

Friday: log and reuse (30 minutes)

• Record what you posted, where, and what happened: replies, signups, quickstart completions. A plain spreadsheet is fine.
• Cut the artifact into smaller pieces for next week: a code snippet for social, a docs improvement, an FAQ entry.
• Note one question from the comments. That is next Monday's topic candidate.

Channels and their norms

Each community has written rules. Read them before you post, not after a moderator removes your post.

Hacker News

Hacker News is fine with you posting your own work part of the time, but its guidelines say plainly not to use the site primarily for promotion and not to solicit upvotes, comments, or submissions. Titles should be plain: no uppercase for emphasis, no exclamation points, no linkbait.

Show HN has its own rules. It is for something you made that people can try, not a blog post or a landing page, and readers should be able to try it without signing up. You should be around to discuss it. If your weekly artifact is a deep dive, submit it as a normal story. Save Show HN for when there is something to run.

Reddit and niche forums

Subreddits and forums set their own self-promotion rules, usually in the sidebar or a pinned post. Read them per community. The rule of thumb that holds almost everywhere: participate before you promote. If your account history is nothing but links to your own site, expect to be removed.

Product Hunt

Product Hunt is a launch event, not a weekly channel. Its own guidance says to ask for feedback and comments, not upvotes, and not to spam communities you have not been active in. Use it for a meaningful release, a few times a year at most.

Your own channels

Your blog, docs, changelog, newsletter and GitHub README are where compounding happens. Every weekly artifact should live on one of them. Search traffic and returning readers come from owned pages, not from yesterday's front page.

Social feeds

Post the most interesting snippet or chart from the artifact, with a link. Write it as an engineer would to a peer. Skip threads that stretch one idea into twelve posts.

How to tell if it is working

Skip vanity numbers. A small team can track four things:

• Qualified visits to docs or quickstart from each post.
• Time to first success: how many visitors complete the quickstart.
• Conversations started: replies, issues, emails from people with real use cases.
• Reuse: how often you link to an old artifact when answering a question.

A useful heuristic: give the cadence eight weeks before judging it. Single posts are noisy. The pattern over two months is the signal.

What to skip

• Scheduling tools and dashboards before you have eight posts. A text file works.
• Paid promotion until you know which artifact types convert.
• Ghostwritten "thought leadership." Developers can tell. Write what you know, in your own voice.
• Cross-posting the same text everywhere. Adapt or skip.

Checklist: start this week

• Write five specific titles from last month's support questions and issues.
• Pick one and draft it as a working example with runnable code.
• Test every snippet from a clean environment.
• Publish on your own domain with one call to action.
• Read the rules of the one or two communities you will post in.
• Post with a plain title and stay to answer comments for a few hours.
• Log the post, channel, and results in a spreadsheet.
• Add one question from the comments to next week's list.
• Block four hours on your calendar for the same slot next week.

Do this next

If you want the positioning, messaging and launch plan that make each weekly post land harder, The Developer Launch Kit gives you the templates, a fully worked example and agent skills that draft from your repo. It comes in three editions: Kit (49), Complete(99) and Team ($249).

Get The Developer Launch Kit: https://shiptodevs.com/#pricing

Sources

• Hacker News Guidelines: https://news.ycombinator.com/newsguidelines.html
• Show HN Guidelines: https://news.ycombinator.com/showhn.html
• Y Combinator, "Make Things and Show Them": https://www.ycombinator.com/blog/make-things-and-show-them
• Product Hunt, "Sharing your launch": https://www.producthunt.com/launch/sharing-your-launch