Concepts
Build in public
Build in public means sharing your progress while you are building, instead of waiting until a project is perfect before showing it.
For developers, building in public can turn everyday progress into proof of work. It shows what you are learning, what you are building, what problems you are solving, and how your project improves over time.
What does build in public mean?
Building in public means documenting the journey behind your work.
Instead of hiding every project until launch day, you share meaningful updates while the project is still active.
These updates can include:
- What you are building
- Why you started the project
- What features you are working on
- What bugs you found
- What technical decisions you made
- What you learned
- What you plan to do next
The point is not to share every tiny detail. The point is to make useful progress visible.
Why building in public matters for developers
Many developers learn quietly. They build projects locally, make progress, struggle through bugs, and improve over time — but almost nobody sees it.
That creates a problem. When it is time to show skill, there may be no clear record of the work.
Building in public solves this by creating a visible history of effort, decisions, mistakes, fixes, and progress.
It helps prove that you are not just collecting tech stack names. You are actually applying what you learn.
Build in public is not fake hype
Building in public does not mean pretending every small update is a major startup announcement.
You do not need to write dramatic posts like:
Huge news. I changed a button color. The future of software is here.
That is not the goal.
A better build-in-public update is honest and useful:
I redesigned the project creation form today because users were getting confused between live projects and finished projects. The new version separates the two actions more clearly.
That kind of update shows product thinking, user awareness, and real development progress.
What should you share?
Share updates that help others understand the project and your growth as a developer.
Good things to share:
- A feature you built
- A bug you fixed
- A design decision
- A database change
- A deployment update
- A blocker you faced
- A lesson you learned
- A user feedback change
- A milestone you reached
You do not need to share private information, secrets, API keys, user data, or anything that creates security risk. Build in public does not mean leak your house keys to the internet.
Where Devmaniac fits in
Social media is useful for quick posts, but updates disappear fast. Devmaniac gives your build-in-public work a structured home.
Instead of scattering updates across random posts, you can organize them under live projects.
A Devmaniac live project keeps your progress connected to the project itself. That makes it easier for others to understand the full story.
On Devmaniac, build-in-public work can include:
- Live project pages
- Project journals
- Milestone updates
- Bug fix notes
- Deployment updates
- Technical decisions
- Finished project showcases
Build in public vs normal portfolio
A normal portfolio usually shows what you finished.
Building in public shows how you got there.
| Normal portfolio | Build in public |
|---|---|
| Shows final results | Shows progress over time |
| Often hides mistakes | Can show bugs, fixes, and lessons |
| Good for polished presentation | Good for proving consistency |
| Usually static | Updates as you build |
| Shows what you made | Shows how you think |
Both are useful. Devmaniac combines both by supporting live projects and finished projects.
Who should build in public?
Building in public is especially useful for:
- Students building coding projects
- Self-taught developers creating proof of work
- Hackathon builders documenting progress
- Developers learning a new stack
- Indie hackers building products
- Open-source builders improving tools
- Early-career developers trying to show consistency
It is useful because it gives people a way to see your work before you have a long resume or big job title.
Common mistakes
Avoid these build-in-public mistakes:
- Posting only hype with no useful progress
- Sharing private or sensitive information
- Trying to look perfect all the time
- Posting vague updates like “worked on stuff”
- Starting many public projects and updating none
- Writing for attention instead of clarity
- Confusing build in public with oversharing
The strongest public builders are not the loudest. They are the ones who show useful progress consistently.
Simple build-in-public update template
Use this when you do not know what to write:
Today I worked on [feature or task]. I did this because [reason]. The main challenge was [problem]. I solved it by [solution]. Next, I plan to work on [next step].
Example:
Today I worked on the live project journal system. I did this because users need a way to document progress inside each project. The main challenge was connecting entries to the right project. I solved it by updating the backend relationship and testing the create endpoint. Next, I plan to display journals in a timeline.
The core idea
Build in public should answer:
What am I building, what am I learning, and what proof am I creating through real work?
If your updates answer that, you are building in public the right way.