A corporate app store is one of those things that sounds like a convenience feature and turns out to be a control. Three groups benefit from it, and they benefit in different ways.
What end users get
Without a catalogue, requesting software is an unrewarding experience. You work out who to ask. You email them. You wait. You do not know whether the request was received, whether it needs approval, who is supposed to approve it, or whether it has quietly died in someone’s inbox. If the software is for a phone rather than a laptop the route is different again, and you may have to start over.
The predictable result is that people stop asking. They find something free, or they expense something, or they do without and work more slowly. None of those outcomes is good, and the first two are worse than the request would have been.
A catalogue replaces that with one place and a visible state. In App-Centre a user browses what is published to them, requests what they need with a reason attached, and sees what is happening: awaiting approval, awaiting install, being installed, already installed. They receive confirmation when the request is logged and again when it is approved or rejected. If the application they need is not listed, there is a route to ask for it rather than a dead end — which is also how you find out what your catalogue is missing.
Users can also remove software themselves. That sounds trivial and is not. The alternative is that unused software stays installed forever, because uninstalling it requires raising a ticket and nobody raises a ticket to make their own life marginally tidier.
What IT gets
Two things: fewer routine tasks, and better information.
The routine tasks go first. A published application can be tied to a deployment procedure so that approval triggers installation without anyone picking up the request. What remains for IT is the exceptions and the genuinely new requests, which is the work that actually needs judgement.
Permissions are enforced at the point of request rather than argued about afterwards. A user who is not entitled to an application is told so; a user who already has it installed is told that too, which removes a surprising volume of duplicate requests. Approval routes to nominated approvers, who approve or reject with a recorded reason, and everyone with an interest is notified of the outcome — the requester, and any co-approvers.
The one setting worth thinking about carefully is the approval timeout: how long the system waits for a response before it takes the default action. Approval chains fail in practice not because people reject things but because they do not answer, and a request that sits unanswered for three weeks teaches users that the catalogue does not work. Set it deliberately.
The information matters more in the long run. Every request carries a reason, an approver, a decision and a timestamp, and every deployment records the application, the action, the user, the machine and the address it went to. That is an audit trail assembled as a by-product of doing the work, rather than reconstructed later from memory.
The catalogue is also branded — your logo, your header colour — which sounds cosmetic but is not. It is how IT presents its offer alongside the external cloud and app store options users can already reach. A shabby internal catalogue loses that comparison.
What the organisation gets
Three things: lower software cost, less risk and better security.
Lower software cost
Centralising distribution means the usage and entitlement data arrives in one place instead of being spread across deployment tools, spreadsheets and people’s recollections. That is the data you need in front of you when a renewal conversation starts.
The larger saving is on the other side of the transaction, and the original version of this post skipped it. Getting software to people is half the job; getting it back is the half that pays. File-based usage metering records first and last use per title and produces a utilisation figure over a rolling 90-day window, so you can see what has been installed and never opened. Combine that with self-service uninstall and you have a reclamation route that does not require chasing individuals. The licence goes back into the pool and gets reissued instead of repurchased.
Less risk
Publishers have not become less assertive about compliance since this post was first written. For anything the catalogue provides, deployment and use are tracked at every stage of the lifecycle — requested, approved, installed, used, removed — which is a far better starting position than reconciling install counts against purchase records after a letter arrives.
Prohibition rules work alongside the catalogue rather than instead of it. Software that is not permitted can be blocked rather than merely reported, and Governance Policies express the required state as rules evaluated continuously. The catalogue is the permitted path; the policies are what happens when someone takes a different one.
Better security
Shadow IT is not usually malice. It is what happens when the approved route is slower than the unapproved one. A catalogue that delivers in minutes removes most of the motive, and what remains is easier to see because it stands out against a legitimate baseline.
Personally owned devices widen this considerably — the mix of hardware in most organisations is now well beyond what IT issues, and each of those devices is a route by which software arrives without passing through anything. Managing that mix means covering it, not excluding it.
This is where the 2016 version of this post has been overtaken by the product. The complaint it opened with — that requesting software for a phone follows a different route from requesting it for a laptop — no longer holds. CerteroX ITAM covers both: App-Centre for desktop software distribution across MSI, EXE and Click-to-Run packages, and mobile device management for iOS and Android with a company app store, Apple Device Enrolment Program support and volume purchasing. Blacklists apply to the mobile side, and are deliberately prevented from contradicting the catalogue — you cannot blacklist an application you are also publishing to users, which stops the two controls disagreeing in a way nobody notices until it breaks.
Where the problem has moved
The honest reading of this post ten years on is that its argument survives but its subject has shifted.
In 2016 unsanctioned software meant an installer. Today it is a signup. Someone enters a work email address, clicks through a consent screen and now a third party has read access to a shared drive. No download, no admin rights, nothing for a desktop catalogue to catch.
The response is the same in principle: give people a fast approved route, and see the rest. CerteroX SaaS Management discovers what is actually in use through three converging signals — identity provider sync, vendor connectors and a browser extension with per-user attribution — against a catalogue of more than 35,000 applications, with 47 connectors shipping today. Overlapping applications are ranked by recoverable saving, so the rationalisation conversation starts with evidence rather than opinion. Licences unused for 30 days or more surface for reclaim, reassignment or downgrade.
AI tools get their own treatment, classified from application feature tags rather than a fixed list so the detection set keeps up with the market, and ranked by how much of the organisation is using each one.
The pattern is exactly the one this post described for desktop software in 2016. Make the sanctioned path the easy path. Instrument everything so the unsanctioned path is visible. Then reclaim what nobody uses, on a schedule, rather than at renewal.
To see App-Centre, usage-based reclamation and SaaS discovery working end to end, book a demo.