[10ren]

At the moment, their primary task is actually to gauge/encourage interest - without that, they have lost.

A following task is to discover if what they have is usable/useful by real people, and the only real test of that is to release it and get feedback. Related is flushing out bugs (most effectively done by actual usage); testing performance (even for small numbers of users); and of course flushing out specific privacy and security issues. Note that it's not actually necessary to even continue with the same codebase; it is possible to use it as a prototype.

I think a helpful way to separate a "product" from a "codebase" is to ask whether a complete rewrite in a different language with a different internal architecture (and of course codebase), that is indistinguishable to users, could be sold as the same product.

I think the Mythical Man Month would be of interest to you; he has your perspective, but with a wider scope. I think you'd really enjoy it, if you haven't already. Some fascinating ideas appear right up in chapter 1, very clearly written.

[10ren]

It's fun to think of a software product as a giant ADT (Abstract Data Type), as it specifies operations that may be carried out (via a GUI, or command line, or webpage, or webservice, etc), while the detail of the implementation of those operations is hidden. Each instance (running copy) of a software product contains its own data.