BUILD IN PUBLIC — YOUR STARTER WORKSHEET
Buildside | https://www.buildside.app/build-in-public

MY PURPOSE
Sharing my work should help me:
The person I want to reach:
The task they need to complete:
My main place to share:
My public / permission-needed / private boundaries:

MY FIRST UPDATE
I’m building:
For:
What changed:
What I’m learning:
My specific question:

FOUR-WEEK STARTER PLAN

WEEK 01: Make the problem visible
Write down the user, their recurring task, and the uncertainty you want to resolve. Choose your sharing boundaries and a main channel. Read the community’s norms, contribute to a relevant discussion, and introduce the work with a sketch or clear problem statement. You can start before the product exists; be precise about what is still an idea.
Leave with: One introduction, one useful question, and a record of the replies.
Review: Did the response come from someone who knows the problem?

WEEK 02: Show one small piece
Choose a screen, workflow, or prototype that makes the question easier to answer. Show a short sequence rather than an unexplained screenshot. Ask someone to describe what they expect to happen next. If they are willing to test, agree on the task and time involved. Record what they actually do separately from what they say they like.
Leave with: One demo or prototype update and a short observation note.
Review: What did you learn that a like or upvote would not tell you?

WEEK 03: Act on the learning
Group responses by the problem they describe. Decide which observation deserves a change and which needs more investigation. Ship a small improvement if the evidence supports it, or explain why you are keeping the current approach. Share the reasoning in a follow-up. Thank people for specific contributions without implying they endorse the product.
Leave with: One decision, the evidence behind it, and a public follow-up.
Review: Can a new reader understand why the decision changed?

WEEK 04: Review and choose a rhythm
Look back at the questions you asked, relevant conversations, product changes, and time spent. Check visits or signups if you measured them, but keep unattributed outcomes separate. Decide whether to continue with the same audience, narrow the question, try a different channel, or reduce the frequency. Choose a routine that leaves enough time to build and serve users.
Leave with: A monthly recap and one focused goal for the next month.
Review: Would you repeat this routine even if the follower count stayed flat?

SIX POST TEMPLATES

YOUR FIRST UPDATE
Introduce the problem before asking people to care about the product. Give readers enough context to recognize whether they have relevant experience.

I’m building [product] for [specific people] who struggle with [task].
Right now I’m at [stage].
Here is [a sketch, demo, or observation].
The question I’m exploring is [one uncertainty].
If you do this task, how do you handle it today?

A PROGRESS UPDATE
Explain why the change matters to the person using it. A list of features becomes more useful when the reader can connect it to a task.

This week I changed [specific thing].
Before: [what happened].
Now: [what is different].
I made this change because [reason].
Still unfinished: [limit].
Next I’m checking [question or task].

AN EXPERIMENT
Separate the hypothesis, the test, and the result. Describe the conditions so readers can judge what the observation does and does not support.

Hypothesis: [what I expected].
Test: [what I changed and how I checked it].
Context: [dates, participants, environment].
Observed: [what actually happened].
Limits: [what this cannot tell us].
Next: [follow-up test or decision].

A FOCUSED FEEDBACK REQUEST
Make the task and the requested response explicit. If trying the product takes time or requires an account, say that before someone volunteers.

I’d value a perspective from [relevant person].
Task: [what a user is trying to do].
Current approach: [brief description or artifact].
Question: [one thing to evaluate].
Trying it involves [time, access, prerequisites].
Please avoid sharing [private information].

A SETBACK OR CHANGED ASSUMPTION
Describe the failure without turning it into a performance. Explain the impact, what you know, and the next responsible step.

I expected [assumption].
Instead, [what happened].
This affected [specific task or plan].
What I know: [evidence].
What I don’t know yet: [uncertainty].
I’m changing [next step].

A MILESTONE WITH CONTEXT
Define the number, its timeframe, and its limits. Readers should be able to tell signups from active users and interest from paid demand.

Milestone: [number or completed outcome].
Period: [start and end dates].
Definition: [exactly what is counted].
What contributed: [known activities].
What I cannot attribute: [limits].
Next priority: [how this changes the work].

WEEKLY REVIEW
Post and date:
Purpose:
Relevant replies or observations:
Decision and why:
Next check:
Time spent:
Measured visits / registrations / activation (if available):
Attribution limits:

Use these prompts anywhere. Replace placeholders with facts. Keep private data private.