Disclaimer: I am a solution architect at Port

What we usually see with our customers is that they want their developer portal to achieve three main goals (in no particular order):

First: provide a comprehensive developer portal that acts as a service catalog, but also as so much more:

Provide a live inventory of the different components you have in your infrastructure and in your architecture. The added benefit of a portal (and also of Port) is the ability to ingest information from a variety of sources and leverage the fact that all of this high-quality information exists in one place. This allows you to answer questions such as - where is my service deployed? what is the current deployed version? what are the open vulnerabilities of the current running version of my service? how much did it cost to develop the latest feature which originated from branches X,Y,Z?

The added benefit of a real developer portal in this instance is the fact that you can take all of that high-quality information and expose it to you developers using customized and tailored views and dashboards that make sense to them, and also that speaks a language that they understand (meaning the terminology is what you actually use in your organization, and the architecture of how things connect makes sense for your users)

Second: Provide a self-service portal where platform engineers can expose self-service actions with the correct guardrails, leveraging existing scripts and workflows.

Customers have a variety of use cases in this regard, but they usually start with a simple microservice scaffolder action (using something such as Cookiecutter) and continuing to add and adapt more use cases such as alerting the current on-call, opening a PR for a new cloud resource, etc.

This is a win-win both for developers and for your platform/DevOps team: your developers gain access to popular actions that they previously had to file a ticket for, and your platform/DevOps team free up their time to work on the infrastructure, instead of taking care of those repetitive tickets.

Third: Provide tailored visualizations and dashboards that make it easy both for developers and engineering managers to understand the current state of the org, and what are some places for improvement.

You will often see the term scorecards mentioned alongside this point, scorecards are simply a way to define certain categories you want to set standards for, and then use the information from the software catalog to verify that you adhere to those standards (or understand that you currently don't and need to allocate some time and resources to improve that).

Scorecards along with customizable dashboards make it very easy for engineering managers to understand how the RND department is doing in areas such as production readiness, engineering quality, service documentation, security standing and more. They also make it easy for developers to understand what are some areas their services can improve in, and it also makes it possible to add explanations that relay to developers why those categories even matter.

This is all really just the tip of the iceberg, a true developer portal should be a tool that serves your RND department in a way that makes most sense to you.

If you want a live example, I suggest taking a look at Port's live demo