Building in public creates free marketing by turning the work behind your startup into something people can discover, learn from, and share. A feature you ship, a problem you solve, or a decision you explain can introduce someone to your product without buying an ad.
The word “free” needs some context. Writing posts and answering questions takes time. But you can create those posts from work you're already doing, which makes this approach practical for founders with limited budgets.
Your everyday work gives you something to publish
Think about what happened while building your product this week.
Maybe you simplified onboarding, fixed a frustrating bug, or removed a feature that made the app confusing. Each change has a story: what was happening, why it mattered, and what you did about it.
That story gives readers a reason to pay attention.
For example, a founder could share screenshots of an onboarding flow before and after an update, then explain the decisions behind the change. Another builder gets a useful example. A potential user gets to see how the product works.
Useful posts introduce people to your product
A technical explanation can teach something while showing what you're building.
With Buildside, I've shared how scheduled posts work, including the roles of EventBridge, SQS, and Lambda. That gives developers something concrete to discuss: how jobs get triggered, how work gets processed, and what happens when something fails.
The product becomes part of an explanation readers can use.
You can do the same with a design decision, customer research method, or difficult integration. Choose an example your intended audience will understand. Explain enough for the post to be useful on its own, and include a relevant link for anyone who wants to explore further.
People get context before you launch
Someone who sees an early prototype, reads about a problem you're solving, and later sees the finished feature has a little more context than someone encountering a product name for the first time.
They've had several opportunities to understand who it's for.
That doesn't guarantee a signup. It does give you a clearer starting point for a launch announcement: people can connect the release to work they've already followed.
Share progress while there is still something to discuss. A focused question about an unfinished feature gives readers a way to participate.
Feedback gives you something worth following up on
Public updates can also start conversations that improve your product.
Suppose you share a demo and someone asks whether it supports their workflow. Their question might reveal an unclear explanation, a missing capability, or an audience you hadn't considered.
Investigate before deciding what to change.
If you make an improvement, follow up with the result. Explain the original problem and show what works differently. Anyone following the discussion can see how an observation became a product decision.
This gives your next update a specific reason to exist.
Keep it useful enough to sustain
Building in public can become another task competing with development. Keep the routine small: choose one meaningful change, explain it clearly, and leave time to answer thoughtful replies.
Pay attention to whether those conversations reach people who might use your product. A popular post about a broad topic can attract an audience with little interest in your startup.
Start with your next useful change. Show it, explain why it matters, and invite a specific response.
If you're building a SaaS and want somewhere to share that progress, that's what Buildside is for. Post what you're working on, meet other founders, and give people a reason to follow your product as it develops.
Top comments (0)