Cortex and Backstage are both internal developer portals built around a service catalog, and the choice between them mostly comes down to build versus buy. Backstage is the open-source framework you host and extend yourself; Cortex is the hosted product you configure instead of code. Both catalog your services, owners, and health well. Neither answers "who decided this and why" the way a decision record does, because a catalog is a map of what exists, not a memory of the calls that shaped it.
So the short version: choose Backstage if you have the platform engineers to run and customize it, and Cortex if you want the catalog without owning the infrastructure. Then plan separately for the decision questions, because that gap is identical in both.
What is the difference between Cortex and Backstage?
Backstage is an open-source internal developer portal, originally from Spotify, that you self-host and build on. It gives you a service catalog, software templates, and a plugin system, and it expects your team to assemble and maintain the pieces. The upside is total control; the cost is that you are running and extending a platform.
Cortex is a hosted internal developer portal centered on a service catalog and scorecards. It maps your services, attaches owners and metadata, and grades each service against standards like having on-call set up or a runbook in place. You configure it rather than build it, so it stands up faster, with less platform work.
Both share the same core model: inventory plus standards. You get one place to see what services exist, who owns them, and whether they meet your bar. The split is operational. Backstage trades engineering effort for flexibility; Cortex trades flexibility for a managed experience. Neither difference touches the decision-memory question, which is why teams stuck on "why did we build it this way" do not get unstuck by switching between them.
How do Cortex and Backstage compare head-to-head?
Here is the honest side-by-side. Both ship changes often, so treat this as a map.
| What you need | Cortex | Backstage | A decision record |
|---|---|---|---|
| Hosting | Managed for you | Self-hosted | Managed |
| Setup effort | Configure | Build and maintain | Light |
| Service catalog | Strong | Strong | Not the focus |
| Scorecards and standards | Strong, built in | Via plugins you add | Not the focus |
| Extensibility | Within the product | Open, code-level | Not the focus |
| Ownership metadata | Per service | Per service | Per decision, with the reasoning |
| "Why did we decide this" | Not captured | Not captured | The core job |
| Source of an answer | Catalog fields | Catalog fields | A person's declared record |
| Answer when none exists | Blank field | Blank field | A clear "no record" with the owner |
Both are good at the job they advertise. Cortex gets you a catalog and scorecards with less platform work. Backstage gives you a catalog you can shape to almost anything, if you have the engineers to do it. Where both stop is the reasoning. They will tell you the payments service exists and that Priya owns it. They will not tell you why the team split payments out from billing, what was ruled out, or who made that call, because that was never the catalog's job to hold. If you want the wider field, our Cortex alternatives piece looks past the catalog category entirely.
Why doesn't a service catalog answer "who decided this and why"?
A service catalog is built to store facts about services: name, owner, dependencies, health. Those facts are stable and structured, which is exactly why a catalog holds them well. A decision is a different kind of data. It is tied to a person and a moment, it carries reasoning and rejected options, and it does not fit in a metadata field.
So you can have a perfect catalog and an empty decision history sitting right next to each other. The inventory is complete, ownership is current, every scorecard is green, and you still spend an hour reconstructing why a service was designed the way it is. That reasoning was never captured anywhere structured, and the catalog points you to a person who then has to rebuild the history from memory, assuming they were there at all.
For a distributed team the cost is sharper. The owner the catalog names might be asleep, or gone, when the question lands. A catalog tells you who to ask. It does not answer for them, and when the only record of a decision is in someone's head, "who owns this service" is a long way from "why was this call made." Our piece on engineering team handoffs and context loss walks through how that reconstruction tax adds up.
What is a decision record, and how is it different?
A decision record is a system that answers "who decided this, when, and why" with a named source the person stood behind, rather than a metadata field or a doc you go read. Where a catalog stores facts about services, a decision record returns an answer a real person vouched for.
It works in two steps. Auto-indexing makes each person's work findable and pointable, so the system knows where the relevant material lives without anyone filing it. Declaring is the separate human step where someone vouches for an answer as their own and puts their name on it. Indexing makes the work discoverable; declaring is the moment a person says "yes, that decision was mine, you can quote me."
The restraint is what makes it trustworthy. It answers only from declared records. It never generates a decision in someone's name, and when nobody has declared an answer, it says "no record" and points to the likely owner. A catalog field left blank leaves you guessing whether the call was made and lost or never made at all. A decision record tells you plainly which it is, and that distinction is worth a lot when you are deciding whether to redo work.
You can see how indexing and declaring turn day-to-day work into answerable decisions in how StandIn works.
Should you run a developer portal and a decision record together?
Usually, yes. They are different categories and they do not compete. Keep Cortex or Backstage for inventory, ownership, and readiness scoring, which a decision record does not produce and should not try to. Add a record for the questions that the catalog cannot hold, the ones about why a system is shaped the way it is and who made the call.
The mistake is asking the portal to answer decision questions it was never built for. When you let the catalog do what it is good at and put the "why" somewhere it gets a named, sourced answer, both tools get easier to trust and your team stops paying the reconstruction tax.
Frequently Asked Questions
Is Cortex or Backstage better?
It depends on build versus buy. Backstage is open-source and self-hosted with deep customization, suited to teams with platform engineers to run it. Cortex is hosted and configured rather than built, so it stands up faster. Both catalog services well and neither captures decisions.
Does a developer portal capture decisions?
No. Cortex and Backstage store facts about services, like owner, dependencies, and health. The reasoning behind a choice is tied to a person and a moment, and it does not fit in a catalog field, so a portal points you to an owner rather than answering why a call was made.
Does a decision record replace Cortex or Backstage?
No. A portal manages service inventory and readiness; a decision record answers who decided what and why. Teams that need both run them side by side.
How does a decision record know who decided something?
A person declares the decision as their own, which puts their name on the answer. The system returns only what someone vouched for, and refuses when no one has.
What happens when a decision was never recorded?
The record says "no record" and points to the likely owner, instead of showing a blank field. That tells you the call was never made and who should make it.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to retire your daily standup?
Distributed teams use StandIn to start every shift with full context, no standup required. Engineers publish a 60-second brief. The next shift wakes up knowing exactly what to work on.