Build in Public on Indie Hackers: How to Start, With Tips and Examples for 2027

Build in public on Indie Hackers by sharing real progress, numbers and lessons while other founders follow along. This guide covers how to build in public, with build in public tips and build in public examples you can copy. Pair it with a clear startup description and, later, a plan for how to launch on Product Hunt and other startup communities.

What building in public means on Indie Hackers

Building in public means sharing your product's progress while you are still making it. That can include what you shipped this week, what broke, what you learned from a user, and sometimes revenue or traffic numbers. The point is to turn a private project into a story that other people can follow, question and help with.

Indie Hackers is a natural home for that. Its about page describes a community where founders share their stories and can submit posts to ask for help and feedback. It also has a Products section where you can add your own product, and it says the community's upvotes decide which items appear in the weekly newsletter. In other words, the platform is built around founders talking about the work, not only announcing finished launches.

One thing worth knowing: the about page does not list rules for self promotion. Its terms of service cover things like removal of content and restrictions on commercial use, so read them before you post anything that looks like an advert. Beyond that, the safest guide is the community's own habit: give something useful first, then mention your product where it fits.

Why founders do it

The benefits people usually list are practical rather than magical:

• Earlier feedback. People can tell you that your pricing page is confusing before you spend a month on it.
• Accountability. Telling readers you will ship something on Friday makes Friday matter.
• A small audience that already knows you. When you launch, there are a few people who recognise the product.
• Trust. Showing the work, including the failures, tends to feel more honest than a polished announcement.

A widely read Indie Hackers post on transparency makes similar points and suggests defining your goal before choosing what to share. It is also written by a payments company that promotes its own blog, so treat its example figures as claims rather than facts.

There are costs too. Writing in public takes time away from building, critics can be blunt, and an audience made up mostly of other founders may not be your customers. Some founders argue that other networks reach a wider audience than Indie Hackers. The honest framing is that when you build in public on Indie Hackers, you are learning and being seen by your peers, not buying a guaranteed route to customers.

How to build in public, step by step

You do not need a complicated system. This sequence works for a solo founder with a few spare hours a week.

1. Write down one goal

Failory's guide to building in public is clear that consistency matters, and consistency is easier when you know why you are posting. Choose one main aim for the next three months:

• Get feedback on a prototype.
• Find your first ten users.
• Stay accountable while you build.
• Build a reputation before a launch.

Each goal changes what you post. A feedback goal means you share screenshots and ask specific questions. A first users goal means you post what the product does and who it is for. An accountability goal means you share small commitments and then report back.

2. Choose one channel and use Indie Hackers as your base

The same Failory guide suggests choosing a channel for two reasons: your customers are there, and the format suits you. For many software founders, Indie Hackers fits the second reason well, because it rewards longer written posts rather than quick hot takes. It is also one of several founder communities where you can find peers, so you do not need to be everywhere at once.

If your customers are not founders, think about where they are. A project management tool for builders may find its buyers on Indie Hackers. A tool for dentists probably will not, and you may use Indie Hackers for feedback and another channel for sales.

3. Set a rhythm you can keep

A realistic starting point, offered as a suggestion rather than a rule:

1. One short progress post each week.
2. One longer post each month with numbers and lessons.
3. A few minutes each day replying to comments and joining other founders' threads.

If you cannot keep that rhythm, cut the frequency, not the quality. Failory's guide warns that efforts which stop after a few weeks rarely deliver the benefits, so a slower plan you keep is better than a faster one you drop.

4. Decide what to share and what to keep private

Sharing everything is not the goal. Use this as a starting point:

FeedBear's guide to building a product in public includes a section on whether you can share too much. Its argument is that execution and the team matter more than secret processes, which is a fair reason to be open about the work. The decision about numbers is still yours. Failory advises sharing only what you are comfortable sharing, and you can always start with progress and add figures later.

5. Write the post, not an advert

A good progress post is short, specific and ends with a question. Here is a structure you can copy:

Title: What I shipped this week, and the one thing I got wrong

1. Where things stand (one or two lines with a real number)
2. What I shipped
3. What went wrong and what I learned
4. What I am trying next week
5. One specific question for readers

The last line matters most. "Thoughts?" invites nothing. "Is the pricing page clear to you in five seconds?" invites a useful answer. If you want your one line pitch to land, the startup tagline examples in our guide show how much a short, plain sentence can carry.

6. Reply to everyone

Dodo Payments' guide to building in public suggests gathering feedback through polls, AMAs and early previews, keeping a public roadmap and crediting users whose ideas ship. You do not need all of that, but the principle is sound: close the loop. When a reader suggests something, say whether you will do it. When you ship it, say so and thank them.

7. Review every month

Once a month, look at which posts led to useful replies, which led to signups, and which led to nothing. Do more of the first two. Then check whether you are still enjoying it. If the posts have become a chore, shorten them.

Build in public tips for Indie Hackers

These habits make the biggest difference on this particular platform.

• Lead with the lesson. A title that promises something specific, such as "What I learned from my first ten users", beats "Update #14".
• Be honest about small numbers. Posting "three signups this week" is more credible than a vague claim, and readers respond to honesty.
• Comment on other people's posts. Contribute before you ask for attention. Founders notice who helps them.
• Ask one question per post. Several questions split the replies and make it harder to answer.
• Link sparingly. Put the product link where it helps the reader, not in every paragraph.
• Do not ask for upvotes. Ask for opinions instead. The platform's own newsletter selection runs on community upvotes, so earn them with useful posts.
• Keep a recurring format. A weekly post with the same headings is easy to write and easy for readers to follow.
• Say when you change your mind. Reversing a decision in public builds more trust than defending a weak one.

If you also launch elsewhere, keep the story consistent. Your Indie Hackers history becomes useful background when you follow a product hunt launch guide, because you can point to real feedback that shaped the product.

Build in public examples worth studying

The most-cited examples are worth reading for the habits, not the headline numbers.

Buffer. Its open page says the company has shared its finances and its team's salaries since 2013, and describes itself as a transparent company since 2010. The page lists monthly metrics, shareholder updates and a history timeline. Lesson: transparency can be a standing policy, published in one place, rather than a series of occasional posts.

Ghost. Failory reportedly points to a 2014 report in which Ghost shared revenue and traffic. Lesson: periodic reports can work as well as constant updates.

Pieter Levels. Failory links to an early 2018 tweet and presents him as a well known example of a solo founder sharing progress, and Dodo Payments reportedly says he has shared traffic and revenue data since 2014, attributing it to Indie Hackers. Lesson: a long run of small, regular updates compounds.

Baremetrics. FeedBear reportedly says the company has published its financials since 2014. Lesson: when your product is about metrics, showing your own is a natural proof.

GrowSurf and Copy.ai. FeedBear uses both as examples, citing a GrowSurf company story and the Copy.ai founder's Twitter updates. The figures in those stories are self reported by the companies, so use them for ideas, not as benchmarks.

Failory also devotes a section to startups that stopped being open. That is a useful reminder that you can scale transparency down as the business grows, as long as you are honest about it.

A caution about all of these: most of the numbers in third party guides come with no method or source, and some look wrong when you check them. Rely on the founder's own pages, such as Buffer's, where you can.

Common mistakes

• Starting without a goal. You will post randomly and measure nothing.
• Posting only wins. Readers learn more, and trust more, from honest setbacks.
• Treating it like an ad. Posts that exist only to link to a product tend to get ignored.
• Oversharing. Customer data and private disputes do not belong in public.
• Burning out. A weekly post you keep for a year beats a daily post you drop in a month.
• Vanishing after launch day. The audience you build in public disappears if you stop showing up.

Frequently asked questions

Summary

To build in public on Indie Hackers, set one goal, post on a rhythm you can keep and reply to everyone. Review these build in public tips, borrow from the build in public examples, and recheck how to build in public each quarter. Then decide where to share your startup next, refine how to describe your startup and plan a product hunt launch strategy for the day you ship. If you are not listed yet, submit your product to circlesaasboard.com.