CB
Back to Writing

Product Building

Small Products as Research-Adjacent Practice

小产品作为研究相邻的实践

A public reflection on why small, carefully bounded products can be useful evidence of implementation capacity without pretending to be clinical research.

2026-06-19/product prototypes / digital health / privacy boundaries / implementation

Source Frame

Synthesized from private Obsidian notes on SeYun Outfit, app launch planning, payment boundaries, App Store review preparation, and the personal website strategy.

A prototype is not evidence by itself

Building a small app is not the same as conducting a clinical study. A consumer product does not become a validated intervention because it has a polished interface, and a working prototype does not prove efficacy. This distinction matters to me because my long-term direction sits near psychology, digital health, AI-assisted self-reflection, and product implementation.

The value of small product work is different. It shows whether an idea can be reduced into a usable flow, whether privacy boundaries can be explained clearly, whether claims can be kept conservative, and whether a person can move from concept to shipped artifact without hiding uncertainty.

The discipline of keeping V1 small

One of my Obsidian themes is the danger of expanding a first version before it has earned complexity. A small product should answer a narrow question. Can a user understand the first screen? Can the core interaction work without login? Can private inputs stay local when possible? Can the product describe itself without promising outcomes it cannot guarantee?

That discipline appeared clearly in my notes on SeYun Outfit. The safer public framing is not prediction, fate, or certainty claims. It is a lifestyle color and outfit inspiration tool with symbolic cultural logic, local-first data handling, and an entertainment boundary. That kind of wording may sound less dramatic, but it is more responsible and more durable.

Implementation as a research-adjacent signal

For prospective supervisors, product work should not be read as a substitute for research training. It should be read as a signal of implementation capacity. Digital mental health research often struggles not only with theory, but also with translation: onboarding, engagement, data minimization, safety wording, support routes, versioning, and user trust.

Small products expose those problems early. A privacy policy forces decisions about data. An App Store review path forces clarity about claims. A support page forces boundaries around what the product can and cannot do. A static website forces public communication to become precise enough for strangers, reviewers, and potential collaborators.

The bridge I want to build

My goal is to build a bridge between psychology training and implementation practice. On one side is psychological assessment, wellbeing, clinical workflow exposure, and patient-reported outcomes. On the other side is the practical ability to build tools that respect users, avoid inflated claims, and can be evaluated seriously.

The best small products are not loud declarations. They are learning instruments. They help a builder discover where the assumptions are weak, where users need clearer language, where privacy risks appear, and where a future research question may become more concrete. That is why I see small, conservative, well-documented products as research-adjacent practice.