How to build a Unity Asset Store tool without exposing source

Private source still needs public trust

A commercial Unity tool does not need a public repository to be credible. It does need evidence. Screenshots, workflow videos, version history, documentation, and clear support boundaries matter more than a pile of source files nobody was going to read anyway.

For tools like BugLens / SceneLens, the source is part of the product boundary. The public surface should be the workflow: capture evidence, export structured reports, reproduce the issue, and hand useful context to a developer or AI assistant. Glamorous? No. Useful? That is the trick.

Package like maintenance exists

The package should make installation boring. Namespaces, assembly definitions, sample scenes, menu items, and documentation need to be predictable. Every surprise in the first ten minutes becomes a support email with a screenshot taken from an unusual angle.

I also prefer changelogs that describe user-facing changes, not only internal implementation. Buyers need to know what changed, what broke, and whether the tool is alive. This is basic courtesy, which makes it strangely exotic.

Draw the support line early

A small tool survives by having a clear promise. It should say what it captures, what it exports, which Unity versions are supported, and where responsibility ends. That boundary is not defensive. It is how a focused product avoids becoming a helpdesk with a toolbar.