What I Gain by Building Clad in Public
Sharing Clad is not about performing progress. It exposes product decisions and analysis limits, turning specific reactions into better changes.
Clad analyzes a photo and turns the result into a personal color palette and beauty recommendations. Instead of waiting for the product to look finished, I share selected decisions while they can still change: what I prioritized, what I cut, where the analysis is uncertain, and what evidence will drive the next revision.
This is different from publishing a daily stream of activity. Commit counts and work-in-progress screenshots show motion, but they rarely explain whether the product is becoming more useful. The material worth sharing is the reasoning behind a decision and what happened after the decision met a real user.
Transparency needs an editorial boundary
Building in public does not require publishing everything. More information can make the important choices harder to see. For Clad, I focus on a small set of questions:
- Which user problem was a change intended to address?
- Why did I choose this approach over the available alternatives?
- Under which input conditions does the analysis become less reliable?
- What did I change after observing actual use?
Other material should remain private: user photos, security-sensitive implementation details, and individual results that could be misleading without context. Choosing a responsible boundary is part of operating the product, not an exception to openness.
An AI product has to describe its limits
Personal color analysis is sensitive to lighting, camera processing, filters, and how skin is represented on a screen. Showing only the strongest results can make the service appear more stable than it is. That may create a better demo, but it creates the wrong expectation for the product.
The failure conditions deserve the same attention as the success case. Clad needs to explain what makes a photo suitable, why a result is not a definitive diagnosis, and when a user should try again with a different image. Writing about these constraints publicly makes it harder to solve a trust problem with polished language alone.
Useful feedback contains behavior and context
Positive reactions can confirm that an idea resonates, but they do not specify the next product change. The most useful feedback describes where someone paused, how they interpreted the palette, what they expected a confidence label to mean, or what they tried to do after seeing a recommendation.
I do not turn every request directly into a feature. I look for repeated friction, compare it with the current product hypothesis, and find the smallest change that can test the issue. Public work is valuable here because the reasoning remains open to challenge, not simply because the audience is larger.
Contemporaneous notes make better retrospectives
A retrospective written after the outcome is known tends to become cleaner than the real process. Uncertainty disappears. Abandoned options look irrelevant. Decisions that worked can seem inevitable.
Notes captured during the work preserve the assumptions that existed at the time. Whether Clad grows, changes direction, or eventually ends, I will be able to inspect why I made a choice and what evidence was missing. That is the main reason I build in public: to improve the quality of current decisions and leave behind knowledge that remains useful even when a product outcome is mixed.