Solo founder field notes

The Dev Tool Launch Week Playbook

In short:

• Launch week is logistics: channels, slots, and per-platform variants decide reach more than hype volume does.
• Developers do not share announcements. They share things that made them look smart. Ship working demos and honest technical detail.
• Each channel has one native job on launch day. X for reach, LinkedIn for signal, dev communities for conversation, Discord for the people who already trust you.

Launch week for a developer product is a shipping event with a calendar. Supabase runs a week of daily launches roughly every 3-4 months. PostHog deliberately runs rolling announcements instead of a single big-bang day. Both treat the week as an operations problem: who posts where, at what hour, with which variant, and what happens after. The launches that fail treat it as a hype problem and spend the week shouting. This playbook is the channel map, the demo-first rule, the launch-day slot plan, and the week-after sustain plan I use when I take a developer product to market, including my own.

Hype without substance is how you burn a launch

Developers punish hype without substance. They scan a launch post for the demo and the docs, and superlatives read as a warning sign. A launch that cannot show its work does not get a second look.

The evidence is in the launches everyone cites. Supabase’s first big break was a Hacker News post made by an early user, not by the company. Supabase’s own write-up calls it “one of the most upvoted dev tools launches ever, second only to Stripe,” and says databases hosted grew ten-fold overnight. That post worked because it was a working product a developer shared, not a campaign asset. PostHog attributes roughly 97% of its early growth to word of mouth, developer to developer, and its marketing handbook carries the same skepticism about polish: “It’s easy to look at what competitors post on X and feel like we should be slicker, but we pay far more attention to that stuff than the wider world does.”

The practical rule: strip every adjective and see what is left. If what remains is a demo, a price, and a docs link, you have a launch. If what remains is a slogan, you have a problem.

The channel map: X, LinkedIn, communities, Discord, one job each

X is for reach, LinkedIn is for signal, dev communities are for conversation, Discord is for your existing users. Each channel has one native job on launch day. Using a channel for the wrong job is where launches leak attention.

• X: the demo clip and a short thread. Retweets are the fuel, so make the first tweet self-contained: recording, one line, link. This part is my observation from running launches, not a rule handed down by anyone.
• LinkedIn: one longer post in founder voice. Explain the reasoning, name the tradeoffs, link the docs. The note that reads like a decision log wins there.
• Dev communities: one post where the product gets stress-tested. Hacker News Show HN or a subreddit that fits the tool, picked for fit, not for size.
• Discord: your own server gets the announcement hours before the public slots. The people there will catch the bugs before the world does.

When I map a launch, every channel gets its own variant written for that platform’s norms. That is why I built per-platform variants with preview into PostSider, plus channel groups so a launch stays coordinated across 30+ platforms without a spreadsheet. One logical post, rewritten per channel, previewed before it goes anywhere. A variant is not the same headline in a different box. X wants the result, LinkedIn wants the reasoning, HN wants the implementation, Discord wants the changelog. Writing four versions is cheaper than posting one version four times and watching three of them die.

The demo-first rule: show the thing working before you describe it

Lead every announcement with a working demo. A recording of the thing doing its job outperforms every adjective you can write, and you describe it after you have shown it. The demo is the copy.

Hacker News states the doctrine in the Show HN guidelines: “Show HN is for something you’ve made that other people can play with,” and off-topic is “blog posts, sign-up pages, newsletters.” The same page asks you to “make it easy for users to try your thing out, ideally without barriers such as signups or emails.” Playable, real, no gate.

Supabase applies the same instinct inside the company. Their launch story says that with most of the features they ship, “the person who implemented the code will be the same person who writes the marketing content.” The engineer who wrote the feature makes the demo because the demo is the announcement. I apply the rule to every PostSider update: record the real task, run it in front of the camera, show the terminal, let the timestamped clip carry the post. A 45-second recording works on X. The same clip embedded in a community post answers half the questions before anyone asks them.

The launch-day slot map: one channel, one job, one time

Pick a launch hour and hold it. Supabase announces every Launch Week day at 8am PT, and the consistency is part of the habit: the audience knows when to check. Slot the channels around that hour instead of firing everything at noon.

The cadence behind it: Supabase runs a launch week roughly every 3-4 months, one major feature per day, under what the team calls “fixed timeline, flexible scope.” The first launch week, in March 2021, shipped 7 features in a single week. The week is the forcing function, and the daily announcement at 8am PT is the spine. Their growth team has described the cadence as “once every 3-4 months, a week of shipping a new feature every day.”

My slot map for a solo launch day: X at the launch hour with the clip, LinkedIn 60-90 minutes later with the longer note, the community post at a defensible hour for that forum (HN morning US time, subreddit prime time), Discord whenever your server is awake. I schedule the entire day in PostSider’s calendar the night before, per-platform variants loaded with preview, and the posting queue handles the rest. The first comment auto-publishes with the docs link, so every thread on every platform starts with the documentation.

Community posts are conversations you host

A community post is a conversation you host. Posting there means showing up to talk, and the thread is the product’s first real test. Answer every question, take the criticism, and never ask for upvotes. The Show HN guidelines say it without ambiguity: “Don’t post landing pages or fundraisers,” and do not ask friends to upvote.

The etiquette generalizes with local rules. Show HN posts get judged on substance and on the author staying in the thread. Reddit punishes the same post pasted into six subreddits at once; in my observation one well-placed post with an honest title beats three carpet-bombed ones. In every case the founder’s job is to stay in the thread for the first 48 hours and reply to everything, including the harsh comments. The harsh ones name the product gaps for free. My habit is to put the docs link in the first comment on every platform, which is why PostSider auto-publishes that first comment with the post. The thread starts with documentation, not with a sales line.

The week after decides whether the launch compounds

A launch is not one day. In the week after, you answer the threads, publish the write-up, turn the questions into docs, and ship the fixes the feedback named. That is when the launch compounds or dies.

PostHog’s product announcements handbook describes the deliberate alternative to the one-day event: “a smallish launch, followed by shipping lots of stuff the moment it’s ready.” Supabase makes the same point from the other side: you can launch the same feature more than once and still reach people, because audiences arrive in waves. A launch is a wave, and the week after is the next wave. What I watch in that week: docs visits, signups that came from the write-up, and which thread comments turned into actual product requests. The launch thread is a research department with better timing than any survey.

My sustain plan, scheduled in advance so it actually happens: Monday, a reply sweep across every thread, with real answers, not links. Tuesday, the write-up that explains the build, the tradeoffs, and what broke. Wednesday, docs and FAQ entries lifted from the questions people actually asked. Friday, a ship log of the fixes made from launch feedback. I schedule all of it in the same calendar and queue as launch day, which is the part my tooling handles for me; if you want to run the whole plan from code instead of a dashboard, the API schedules posts the same way. The pricing that covers this workflow is plain and predictable, on the PostSider pricing page.

One thing I have not automated, and never will: the demo. The AI inside PostSider does exactly two jobs, a post checker and a caption rewrite. Drafting and scheduling around a launch run on your side, through an agent over MCP or REST, the setup I covered in AI agents in social media marketing. The demo stays human, recorded, and honest, because that is the part developers share. The rest is logistics, and logistics is a solved problem if you treat it like one.

---

I am Lukasz, the solo founder of PostSider. I built the product to run my own publishing, including every launch week I run. When a playbook line reads like the tool I built, it usually is.