Why do you Build in Public?

I like doing it because of quite a few reasons

1. You feel part of a community. I can be lonely building by yourself, but by joining others who are building in public you get a real sense of solidarity. At least I do 😄 I also love seeing others building stuff, and want to be involved with them.
2. Extension from 1., but you can get feedback from others about what you are building (e.g. if a design A looks better than design B) and receive answers to any questions you may have. It's super useful
3. Not sure what the correct word is for it, but I feel like it's calming for my mind to write the stuff I'm thinking about down somewhere. So why not do it in public since it has all the added benefits I mentioned above? It's also nice to read it all back and reflect on your journey.
4. I guess there's also a marketing part of it? I'm not anywhere close to that yet (~100 followers), but even at this scale I feel like it's beneficial.

As @upenv said, most use Twitter for this.

Twitter is to indie hackers what LinkedIn is to professionals.

Personally, it's about building a personal brand and connecting with others. Lots of great people to meet on the platform.

Founder of Micro SaaS HQ - Building the biggest ecosystem of Micro SaaS Builders. This is often asked question to me.

If you are a dev, you will be naturally more inclined to build features rather than talking to customers and doing marketing and sales. Come out of this loop has been tough for most dev founders to get ‘that traction.’

Build In Public - This is the latest trend where most devs keep posting updates typically on social media as they make progress. This could be posting about the landing page they designed, getting the first signup, creating a waitlist, spinning infrastructure, showing the cost of infrastructure, and showing the first paying customer. Note that ‘build in public’ is not always about the positive things. You can also post things like payment bills, hitting churn, losing customers, your product getting hacked, etc. too. Anything and everything that people like to know can come under ‘BuildInPublic’.

This strategy is typically used on Twitter. See more here on the latest Tweets around this hashtag: #buildinpublic https://twitter.com/search?q=%23buildinpublic

Couple of reasons:

1. It's forcing me to come out of my shell, so to speak. I'm an introvert, and therefore I'm inclined to just keep my head down and code. Pushing commits is nice, but my app will never get anywhere if my marketing is lackluster and I never do outreach in the community my app serves.
2. I really like seeing others sharing the progress they make, and I want add to that.
3. Indie hacking a SaaS product is a long road filled with solving many small problems over time. Not many people do this, and so the experience can sometimes feel a little lonely. Sharing helps it feel less lonely.

I try to build in public, I've written blog posts about what I've done and how things went. I try tweeting regularly but I really don't like tweeting regularly. But I'm still mainly building in public.

And here is why, the product I'm working on is basically a SaaS boilerplate (https://getparthenon.com). I decided unlike everyone else with a SaaS boilerplate I didn't want to take money from indie hackers. I want to charge companies money. So instead of having a closed-source library/framework/boilerplate. I decided to make it source available and allow anyone making less than 5k MRR to use it for free. With a $250 USD license. (basically the Jetbrains pricing model). So since it's source available, I could make it public on GitHub.

Since it's available on GitHub and it's something people will be building on top of, it's fair that they would want to know what direction the product is going in, how often it's updated, etc.

So I've created a public issue board on GitHub that is easy to find and in the readme.md for the project - https://github.com/orgs/getparthenon/projects/3.

I literally build it in public in the monorepo. Which then forks out to the bundle repo and the skeleton application repo.

I've gone further and even started to document the design decisions within the code. So people can truly see what I was thinking while building it. Which can be found at https://getparthenon.com/docs/design-decisions.

All this so people can see the building going on. This is all while I continue to blog about tech stuff which is often related to what I'm building. And if they're an indie hacker they can see mines is a different level to others and really providing a flexible solid foundation which will continue to get better. And if they're working at an agency or inhouse they can see it's built for all scales and allow them to grow an application with ease instead of having to workaround issues.