Do not apply an Open Source license unless you actually want recipients of the software to have the freedom to use, modify, and share your software as they want.
The default under copyright law is “all rights reserved”. This is a problem for Open Source / Free (Libre) Software where we want everyone to have Software Freedom. Therefore, different Open Source licenses exist that try to maximize Software Freedom, albeit with different strategies. Since these Open Source licenses contain fixed terms and all guarantee a baseline of rights, everyone can easily know what rights they get, which helped build a large ecosystem of Open Source software. In particular, all Open Source licenses allow commercial use, and allow recipients to modify and share the software.
The Apache-2.0 license is a “permissive” license, which means that Apache-2.0 covered software components can be freely combined with proprietary software. It is perceived as enterprise-friendly, and for example used a lot by the Android project. When other people/companies modify the Apache-2.0 covered software they don't have to keep the same license (they can make their modified versions proprietary) but merely have to provide certain attribution notices. The Apache-2.0 does not require that anyone makes their source code available.
It seems you fully intend for your Product A to stay proprietary. Then, it makes no sense to license it under Apache-2.0. You would be giving other people permission to do things you don't want them to do. For example, the Apache-2.0 allows others to rebrand and re-sell your software. When the libraries you use are available under permissive Open Source license, you are under no obligation to choose an Open Source license for your own software. How a software is developed (publicly or privately) is not directly related to proprietary vs FLOSS licensing.
I think what you actually want is an EULA, terms of service, or similar contract that gives users permission to do what you want them to do, but not more. Since this depends a lot on your specific business goals, there cannot be a “one size fits all” document. Instead, you would likely have to ask a lawyer to draft a custom EULA.
As an aside, there is a small niche of software where the source code is proprietary, but binaries are made available under permissive Open Source licenses. For example, the Mattermost chat server uses a dual-licensing approach for its source code, but binaries are available under the permissive MIT license. This makes it possible to deploy the server without users having to review and accept a custom contract. In principle, people could reverse-engineer the MIT-licensed binaries and create a competing system without being bound by the source code license, but it seems Mattermost is not concerned with that. I'm just mentioning this for completeness – this is probably not a good business strategy unless you really know what you're doing.