Product engineering / 2026-05-14 / 8 min read
How to build a Unity Asset Store tool without exposing source
Private source is fine. Private evidence is where things get awkward.
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, 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.
Show the workflow, not the vault
If the source is private, the public page has to answer different questions. What problem does the tool solve? What does it capture? What does it export? What happens inside Unity? What remains on the user's machine? What does the buyer receive after purchase?
A good product page for a private Unity tool should include screenshots of the editor UI, a short workflow video, example output files, supported Unity versions, known limitations, and a changelog. This is not decoration. This is the substitute for browsing the repository.
Make the package boring
The package should install like it has done this before. A clear namespace. Assembly definitions. No surprise global state. No menu item scavenger hunt. No sample scene that only works on the developer's machine, which is a sacred and unhelpful place.
For an editor tool, I want the first five minutes to be almost dull: import package, open menu, run tool, see result, export report, find documentation. If the buyer has to become a detective during installation, the support burden has already started billing hours.
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.
Protect source without punishing users
Private source does not mean hostile packaging. Users still need enough transparency to trust the tool. Document what data is collected, where it is stored, whether anything leaves the machine, and how reports can be inspected. Local-first behavior is a feature only if people can understand it.
If code is shipped as DLLs, the public contract becomes even more important. Namespaces, API surface, settings, output schema, and versioning need to be stable. The less source a buyer can inspect, the more the product has to communicate through behavior and documentation.
Documentation is part of the product
Docs for a commercial editor tool should not be a tour of buttons. They should explain the workflow. Start with a problem: a bug happens in Play Mode and the report loses context. Then show the capture process, the exported files, the handoff to a developer, and the limits of what the tool can infer.
The most useful docs include a quick start, a real example, export schema notes, troubleshooting, compatibility, and support policy. Nobody wakes up excited to read support policy. That is exactly why it should be clear.
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.
For BugLens, the promise is not to debug the project by magic. The promise is to capture the context before it evaporates: scene, object, component, logs, screenshots, reproduction notes, and structured exports. That is already enough work. Magic can open its own ticket.
The release checklist
Before I would call a private-source Unity tool ready for buyers, I want a versioned package, install instructions, uninstall notes, sample output, changelog, compatibility matrix, screenshots, license text, support email, known limitations, and a clean explanation of privacy boundaries.
This list is not glamorous. It is also the difference between a product and a zip file with aspirations.