BUILDING IN PUBLIC / FIELD NOTE

Building in public without turning the process into a spectacle

What is worth showing while building products in public, how to preserve privacy, and why transparency does not require selling certainty.

A virtual tabletop prototype from the TestaAí lab during development.
Showing the process means explaining hypothesis, decision, and evidence—not pretending a prototype is a launch.

Building in public sounds simple: publish what you are making and invite people to follow. In practice, transparency, usefulness, privacy, and performance stay in tension.

When the record becomes only a sequence of announcements, the audience sees progress without context. When everything is exposed, customers, data, and sensitive decisions are put at risk. The more interesting path lies between: open the reasoning without turning every movement into a spectacle.

What “in public” should mean

Public building does not require livestreaming operations. It requires a story that preserves the parts capable of producing learning:

  • which problem was being investigated;
  • which hypotheses guided the test;
  • which scope was chosen and what stayed out;
  • which evidence appeared;
  • which decision changed because of it;
  • what it cost to reach that point, when the figure can be revealed.

This structure is more useful than a list of finished features. It lets someone follow cause and effect, including when the outcome is negative.

Transparency is not the absence of boundaries

Privacy can be a design constraint rather than a contradiction. At TestaAí, Zero is a stable public identity while civil identity remains protected. The work gains authorship and continuity without requiring irreversible personal exposure.

The same applies to products. Customer information, credentials, private repositories, vulnerabilities, and strategic data do not become editorial material. A good record replaces sensitive detail with enough context for the decision to remain understandable.

The commitment is not to hide the learning. That does not mean publishing anything that places other people or the project at risk.

Show evidence, not only movement

Hours worked, commits, and sleepless nights prove effort. They do not prove value. A more honest record connects execution to an observable change.

For a product, that might be a task completed with less help, a spontaneous return, acceptance of a pilot, or discovery that an integration makes the model unviable. In a game, it might be session length, an abandonment point, or a rule players interpret differently than expected.

Evidence need not be a large metric. A use recording, five consistent conversations, or a recurring error may guide the next version. What matters is explaining the signal’s limit: what it suggests and what it still cannot support.

Avoid three traps

1. Narrating certainty after the result

It is easy to reorganize history so every decision looks inevitable. Preserve the original hypothesis and the criterion set before the test. The distance between expectation and result is where learning lives.

2. Confusing frequency with relevance

Publishing daily does not make content useful. A good record may take longer because it organizes context, evidence, and decision. A sustainable rhythm is more valuable than filling a calendar.

3. Turning vulnerability into a character

Sharing mistakes does not require dramatizing them. A mistake matters when it improves a decision, reveals a constraint, or prevents someone else from repeating the path. Without that, it becomes another performance.

A simple record format

Each update can use five blocks:

  1. Context: where the project stood and which question mattered.
  2. Hypothesis: what you expected to observe.
  3. Test: what was done and which limits existed.
  4. Evidence: what happened, including contradictory signals.
  5. Decision: what changes now and which question comes next.

The format works for a short note, a full article, or a project-card update. It also reduces the temptation to manufacture a moral for every story.

The role of artificial intelligence

AI can organize notes, compare versions, review clarity, and turn raw records into a comprehensible narrative. It must not invent the experience supporting the text.

Authorship therefore remains important. The publisher answers for facts, limits, and interpretation. Technology accelerates editing; responsibility remains human.

Build, record, return to the work

Content cannot consume the experiment it should document. The best cadence fits operations without forcing artificial events.

In practice, record during the work, publish when a relevant decision exists, and keep a clear connection between the text and what is being built. The blog becomes a field notebook, not a stage.

Meet Zero, the person behind TestaAí, and explore the projects behind these records.

FIELD NOTE / BUILDING-IN-PUBLIC-WITHOUT-SELLING-CERTAINTY

Written by Zero from TestaAí experiments. AI may support structure and review; authorship and responsibility remain human.

FROM TEXT / TO PRODUCT

The idea is clear.
Now, test it.

Enter the lab