Internal App Catalog: Build vs Buy for Mid-Size Teams

The phrase "internal app catalog" names two completely different products, and most of the arguments about building one are two people describing different software to each other. One of them means a service catalog: every microservice, library and data pipeline your engineers own, with the team name attached. The other means a directory of tools employees can actually use: the 200-odd SaaS products, internal admin panels and half-forgotten Retool apps that someone in your company pays for.

They share a word and almost nothing else. The first has a mature open-source answer you should probably just adopt. The second doesn't, which is why people keep building it — and why they keep abandoning it eighteen months later. This guide prices both, with vendor numbers checked on 8 September 2026, and is honest about where buying wins.

The two things people mean by "internal app catalog"

Ask five people in a 250-person company what an internal app catalog is for and you get two clusters of answers.

Engineering wants to know who owns this service when it pages at 3am, what it depends on, where the runbook lives, and whether it passed the security scorecard. The entities are services. The audience is 60 engineers. The metadata changes when code changes.

Everyone else wants to know what do we have for this, and how do I get it. Is there an approved tool for expense reports? Who do I ask for access to the data warehouse? Is the marketing team's video editor something I can use, or is it on their credit card? The entities are products and internal apps. The audience is all 250 people. The metadata changes when a contract renews or a team reorganises.

If you meant the service catalog, adopt Backstage instead of building

There is a strong open-source answer here and building your own is hard to justify. Backstage describes itself as "an open source framework for building developer portals," and its docs state it is "a CNCF Incubation project after graduating from Sandbox." The stable release listed on the docs site at the time of writing is v1.54.0.

The mechanic that matters is where the data lives. Per the Software Catalog docs, the catalog "is built around the concept of metadata YAML files stored together with the code, which are then harvested and visualized in Backstage." Components get registered three ways: manually through the UI, automatically when created from a Backstage software template, or by integrating an external source. And on upkeep, the docs are blunt: "Teams owning the components are responsible for maintaining the metadata about them, and do so using their normal Git workflow."

That sentence is the whole adoption question. If your entities are owned by people who live in pull requests, storing ownership metadata next to the code is the correct design — the catalog stays current because it is reviewed like code. If your entities are owned by a finance manager and an office administrator, you have just told them to open a PR to change a phone number.

The honest cost of Backstage is not the licence. It is a framework you deploy, upgrade and staff, and the docs describe it as such. Budget it the way you budget any internal service you now run.

The managed alternative in the same category is Atlassian Compass. Checked on 8 September 2026, its pricing page lists a Free plan for "up to 3 full users, unlimited basic users," a Standard plan and a Premium plan, with the page's own summary quoting $8 and $25 per user per month; the annual-billing toggle displayed $7.67 and $23.96 per user per month. The same page states Compass is "only available on Cloud," so there is no Data Center option.

Before you budget Compass, resolve one thing: the split between billable "full users" and free "basic users." Atlassian defines full users as "billable, paid users in Compass who have access to all features available for their site's plan," and points to a full breakdown of role permissions. If your browse-only employees qualify as basic users, this is a very cheap purchase. If they need a full seat to do what you want them to do, multiply by headcount before you get attached to the idea.

If you meant the employee-facing directory, your SSO portal is not it

The second reflex, and a reasonable one, is that you already pay for an identity provider and it already shows people their apps. Use that.

It is worth checking what those portals actually promise. Microsoft's My Apps overview says users access the portal to "discover applications to which they have access," and spells out the visibility rule: "Only assigned users are able to see the application in the My Apps portal." The same page notes a ceiling — "Only 950 applications to which a user has access can be accessed through the My Apps portal." Okta's docs describe its End-User Dashboard as providing "immediate shortcuts to apps provisioned by your org," and note the recommended app assignment limit rose "up to 5000 apps, an increase from the limit of 2000."

Read those quotes again with the second use case in mind. Both portals are launchers for software you have already been granted. The question an employee brings to an app catalog is the opposite one: what exists that I don't have yet. By design, that is exactly what these portals hide from you.

Entra does have a self-service path, and it is genuinely useful — but the self-service assignment docs require you to enable self-service group management, enable the application for single sign-on, and create a group for application access, and the My Apps documentation limits self-service discovery to apps added through the Entra application gallery, application proxy, or user/admin consent. The internal Retool app your ops team built, the vendor tool that never got SSO, the spreadsheet-plus-Zapier thing that three departments depend on — none of those are in scope.

What a catalog has to hold, and who keeps each field current

Every internal catalog that died did so for the same reason: no named human was responsible for a row. Here is the minimum shape, and the maintenance question attached to each field.

Only two of those fields change often, and neither of them lives in a Git repository. That is the structural argument for a catalog whose editing model is a web form with an owner attached, rather than a YAML file behind a code review.

It is also why the interesting engineering problem is not search or tagging. It is delegation: how a row gets handed to the person who should maintain it, and how you verify that they are that person. We wrote up the mechanics of that in detail in how to hand a listing to its owner without handing it to a stranger; DirectoryLaunch implements it as an email-domain check with an admin review queue for the cases the check can't settle, documented under listing claims.

Build vs buy, priced

Take a 250-person company with 60 engineers and a three-year horizon. All prices are list prices checked on 8 September 2026, and all of them exclude your own engineering time, which is discussed after the table.

The arithmetic on the build rows, because this is where these comparisons usually cheat:

• Licence. DirectoryLaunch Pro is $249 once, with lifetime access and the right to build unlimited sites. Basic is $199. See pricing.
• Hosting. Vercel's Hobby plan docs state that "the Hobby plan restricts users to non-commercial, personal use only," and their fair use guidelines define commercial usage broadly enough that an internal company tool qualifies. So this is Pro: the same page lists developer seats at "$20 per user / month," with viewer seats free. One developer seat is $240 a year.
• Database. Supabase Pro is from $25/month, including $10/month of compute credits that cover one Micro instance — so a single-project org lands at $25/month, $300 a year. The Free plan is not an option for something the company depends on: Supabase's own project pausing docs say it "pauses Free Plan projects that show low activity over a 7-day period."
• Year 1 = $249 + $240 + $300 = $789. Years 2 and 3 are $540 each. Three-year total $1,869.

Now the row that should change your mind if it applies to you. If your security review requires SOC 2 or ISO 27001 from every subprocessor, Supabase's pricing page puts both on the Team plan, from $599/month — not Pro. That is $7,188 a year instead of $300, and the three-year build total becomes $22,533, which is more than three years of Compass Standard for every engineer you have.

Two more honest notes on the build column. It excludes your engineering time, and that is not a rounding error — we wrote a three-point estimation template precisely because first estimates for this kind of project run low. And Supabase's SAML 2.0 single sign-on is a Pro-and-above feature, listed at 50 SSO users included then $0.015 per monthly active user, so wiring the catalog to your identity provider is another line item rather than something you get for free.

Three questions that settle it faster than a feature matrix

Who edits a row when a fact changes? If the honest answer is "an engineer, in a pull request," Backstage or Compass is your product and you should stop evaluating. If it's "the person who owns the contract," you need a web form, permissions and an ownership handover flow — and that is a directory, not a developer portal.

Does anything have to be in it that isn't a repository? Vendor contracts, an internal admin panel with no repo, a physical resource like a meeting room booking system. The moment your list is heterogeneous, catalogs built around source-control metadata start fighting you.

Will procurement's security review touch your infrastructure vendors? If yes, price the compliant tier before you compare anything, because it dominates the total. If no, three years of building and hosting it yourself costs about what seven Compass Standard seats cost over the same period.

If you land on building, the boilerplate case is that the hard parts of an internal catalog are the same hard parts as any directory: a category taxonomy that doesn't collapse, listings with real owners, an admin panel a non-engineer can use, and roles that keep the wrong people out of the edit screen. Those are the parts you would otherwise spend a quarter on. Related patterns for other audiences live in use cases, and the broader vendor landscape — including options we don't sell — is compared in the best directory website builders for businesses in 2026.

Take an inventory before you take a demo

Most of these evaluations start with a vendor call and never produce the one artefact that actually settles the decision: a list of what you would put in the catalog and who would maintain each entry. Do that first. It takes an afternoon and it usually answers the build-vs-buy question on its own.

What to do tomorrow morning

Block ninety minutes and do these four things in order.

1. Pull the actual list. Export enterprise applications from your identity provider and the vendor list from whoever approves invoices. The overlap between those two exports is the shortest honest description of your problem, and the gap between them is usually the reason someone asked for a catalog in the first place.
2. Count what is not in a repository. Take the inventory from the prompt above and compute one number: the share of entities that no engineer would ever open a pull request for. Under 20% and you are buying a developer portal. Over that and you are building or buying a directory.
3. Send one email to procurement. Ask whether a security review of this project would extend to the hosting and database vendors, and whether SOC 2 is required of them. That single answer moves the three-year cost of building by roughly $20,000 in the scenario above.
4. Name an owner for the catalog itself. Not a team — a person, with the catalog in their objectives. Every dead internal catalog had a launch date and no owner. If you cannot name one tomorrow, the honest move is to postpone the project rather than ship a page that will be wrong by Christmas.