Build in Public Platforms - buildinpublic.guide

Begin with a job, not a platform

Do not ask, "Where should I post?" before asking what the post needs to accomplish.

A platform can help you:

preserve technical context;
reach people who experience a problem;
invite a launch conversation;
show visual progress;
publish a durable explanation;
build a direct relationship with returning readers.

No single platform does all of these equally well. A sensible starting system has two parts:

One owned home for the complete, durable context.
One discovery channel where relevant people already spend attention.

Add another channel only when you can explain its different job.

Personal website

Best for: durable essays, project pages, changelogs, case studies, search discovery, and connecting years of work.

Your website is the place where you control structure and context. It should answer what the project is, what exists now, why it matters, and where to continue.

Use it as the canonical version of long-form work. Shorter posts elsewhere can point back to it, but the article should remain understandable without social context.

Watch for: spending weeks designing the publishing system instead of producing the first useful page.

GitHub

Best for: software, open source, technical artifacts, changelogs, issues, discussions, and visible project history.

GitHub turns work into inspectable evidence. A README can be the first public home. Commits show change, releases define versions, and issues create focused conversations beside the code.

A useful repository includes:

a literal description;
current status and limitations;
setup or usage instructions that you have tested;
one contribution or feedback path;
a small history of meaningful changes.

Watch for: assuming that publishing a repository automatically creates discovery. GitHub preserves context; you may still need to introduce the work elsewhere.

X (Twitter)

Best for: short observations, visible artifacts, fast conversations, and meeting people around recurring interests.

Use one post for one idea. Lead with the changed artifact or concrete lesson, then add context. Threads are useful when the sequence genuinely matters, not because every update needs a dramatic format.

Treat the feed as discovery, not the archive. Preserve important decisions on your website, README, or documentation.

Watch for: letting immediate reactions choose the roadmap or compressing complex work into confident claims.

Best for: professional work, operational lessons, career-adjacent projects, services, and reaching people through existing industry relationships.

Explain the situation, decision, and consequence in language a practitioner can use. Screenshots and documents can work when they contain real information rather than motivational decoration.

Disclose your relationship to the project. Write for peers and potential users, not an imagined hiring panel.

Watch for: turning every technical or personal lesson into a universal leadership principle.

Best for: focused problem communities, detailed discussion, honest critique, and reaching people organized around a shared situation.

Each subreddit has its own culture and rules. Read before posting. Provide enough value inside the post that the reader does not need to click your link to understand the contribution.

Good Reddit posts often begin with an observation, experiment, result, or request that belongs specifically in that community.

Watch for: broadcasting the same launch to many communities or hiding that you built the linked product.

Hacker News and Show HN

Best for: working technical projects, unusual systems, developer tools, research, infrastructure, and direct discussion with technically curious readers.

Use Show HN when people can try or inspect the work. Explain what it does, why you built it, what is technically interesting, and what remains limited. Stay present to answer detailed questions.

Read the Show HN guidelines before submitting.

Watch for: launching a landing page with no inspectable artifact or treating critical comments as a customer roadmap.

Product Hunt

Best for: a clear product release that can be understood visually and tried through a polished primary path.

Prepare the name, tagline, thumbnail, gallery, maker comment, and working product before launch day. The maker comment should explain the problem, current version, why it exists, and what feedback would be useful.

Product Hunt is a launch event, not a complete distribution strategy. Follow up with the people who tried the product and publish what the launch taught you.

Watch for: optimizing votes while the product path, support, pricing, or onboarding remains unclear.

DEV Community

Best for: developer tutorials, technical lessons, implementation notes, and articles that can teach independently from the product.

Write the article a developer would still value if they never used your project. Include code and context, disclose your connection, and link to the canonical project only where it helps the reader continue.

Watch for: disguising a product announcement as a tutorial.

Choose from the job

Preserve a technical project: GitHub and a personal website.
Reach a professional niche: LinkedIn and a personal website.
Discuss a focused problem: a relevant subreddit and your public home.
Share small visual progress: X and your public home.
Teach developers: DEV and your repository or documentation.
Launch a working technical artifact: Show HN and your repository or website.
Run a broad product launch: Product Hunt and the product website.

Adapt the frame, keep the facts

The same release may need different introductions:

GitHub needs installation, status, and technical constraints.
Show HN needs the working artifact and interesting implementation choices.
Reddit needs relevance to that community and a transparent disclosure.
X needs one visible change and enough context to understand it quickly.
Your website preserves the complete story.

Do not change claims, hide limitations, or invent urgency between platforms.

Platform checklist

[ ] I can name the job this platform performs.
[ ] Relevant people already use it for this kind of conversation.
[ ] I have read its current rules and norms.
[ ] The post is useful without requiring a click.
[ ] Important context also lives at a durable URL.
[ ] I can remain available for the response I am inviting.
[ ] Adding this platform will not take more time than the work itself.