Choose a project worth continuing

Do not begin with a personal brand

Begin with work. A personal brand is a pattern other people may notice after you repeatedly make and explain useful things. It is not the first project.

A good Build in Public project gives you something concrete to return to when there is no applause. It can be commercially ambitious, but it does not need to be a startup.

Look for three qualities

A real question

The project should investigate something you genuinely do not know yet.

• Can this workflow be reduced to one screen?
• Can I learn enough Go to build this service?
• Will five people use a simpler version of this tool?
• Can I publish one useful technical explanation each week?

A question creates a journey. A declaration such as “I will build the best app” creates pressure without a method.

Visible progress

Choose work that produces artifacts: commits, sketches, screenshots, interviews, drafts, measurements, releases, or decisions. These give you honest material to share.

A reason to continue quietly

Imagine that your first ten updates receive no response. Would the project still teach you something, solve a problem, or create an asset you want? If not, the project depends too heavily on attention.

Reduce the scope

“Build a project-management platform” is too large to guide today's work.

“Build a page where two people can agree on the next task” is small enough to test.

Define the first useful proof:

For: one specific person
Who needs: one specific outcome
I will make: one small artifact
I will know it works when: one observable thing happens

Example:

For: maintainers of small open-source projects
Who need: contributors to understand design decisions
I will make: a simple decision-log template
I will know it works when: one maintainer uses it for a real change

Choose a time box

Set a period short enough to create urgency and long enough to learn. Seven days works for a tiny experiment. Thirty days works for a habit or prototype. Twelve weeks works for a product with real users.

The time box is not a promise that the project will succeed. It is a promise to review the evidence on a known date.

Decide what you will show

List the artifacts the project can produce:

• a weekly changelog;
• before-and-after screenshots;
• a public roadmap;
• short decision notes;
• demos or release links;
• lessons from failed approaches.

Then remove anything that violates the boundary policy from the previous guide.

Project selection checklist

• [ ] The project answers a real question.
• [ ] The first version can exist within the chosen time box.
• [ ] Progress creates visible artifacts.
• [ ] I would still value the work with zero followers.
• [ ] I can describe who it is for in one sentence.
• [ ] I know what evidence will tell me whether to continue.

Your next task is not to announce the project everywhere. Give it one stable public address first.