Developer Portal – what and why? 


Developer Portal – what and why? 

In previous stories, we mentioned the term DX, which means Developer Experience. In brief – it is an interaction with the environment in which developers, testers, and others work. More information can be found in our blog:  

One of the solutions that improve DX is the Developer Portal. It is a place where people can find information from different tools, can interact with their resources, or can register new services. 

We can think about the Developer Portal in the same way as it is done in Azure, AWS, Google Cloud, or Firebase, where resources are visible in one place with a user-friendly frontend.

A need for the Developer Portal comes from the fact, that developers, testers and other people engaged in the software development process need to care about many tools and places. Nowadays, writing a new piece of code usually requires the following things: 

  • Check information from JIRA about a task 
  • Checkout repository 
  • If you do not know the repo – check how it needs to be built and how to execute tests 
  • Familiar yourself with documentation and specification 
  • Write a piece of code and test to cover that 
  • Log hours 
  • Raise a review 
  • Wait for comments, apply comments 
  • Log hours 
  • Wait for results from build jobs 
  • Different stages – build tests, code coverage, vulnerabilities analysis, quality check, etc. 
  • Merge if everything passes 
  • Check results on post-merge jobs and pipelines 
  • Move the task to Done state 
  • Log hours 
  • Keep your fingers crossed that it won’t be reverted 

And that’s not all! We did not mention specific things related to the project – there can be memory leak detection, integration tests, manual testing on the branch, or dependency on other code reviews.  

All of the above increases cognitive load, which we can call something not related to pure work (like coding), but all things that are around and we need to care about. If software development is mostly about creating things that make life easier, why not create something to make developers’ lives easier? 

Here Developer Portal comes. Companies can create such portals from scratch, but there are also options on the market, like: 

  • Backstage, 
  • OpsLevel 

And some more. We will describe them in the next stories, but today we would like to focus on what Developer Portal can offer and what you can use in your company.  

Here are, in our opinion, some of the most powerful features: 

  • Software Catalog 

This is a place where all software components can be found. They can be modules, microservices, helm charts, or docker images – it all depends on what you are working on daily. Such a catalog also includes descriptions, who owns components, there can also be a history of changes, and all relevant information that can help others. For example, if there is a repeatable question about a component, then an answer can be directly under the component in the Software Catalog. It reduces the cognitive load of the person who asks and the person who needs to answer. 

Such a catalog can contain also one other important aspect – relations. It comes very handy when you can go and check which API component is using that belongs to another team. Thanks to that, people can know what  

Everything that you need to know about the software is in one place.  

  • Technical Documentation 

Documentation is another important aspect. It might describe such things as architecture, APIs, instructions on how to build components, or how to execute tests. If people do not know where to find such info (for instance trying to search SharePoint or Confluence) they can be frustrated and do not know how to continue. In the end, they ask someone else, which again leads to increased cognitive load. 

The Developer Portal may contain all documentation in one place. Additionally, documentation can be directly connected to components from the Software Catalog, so it is easily reachable. It is also possible to locate documentation in the repository from which code comes to reach the docs-as-code approach. 


  • Individual Dashboards 

Log in to the Developer Portal gives the ability to customize a view. In big projects, we may have many different groups of people who are interested in something else. Not only because they own different pieces of software or work with such, but also because they may have different positions in the company.  

Developers might want to see APIs, testers – the result of Jenkins jobs, and project managers – the velocity of teams. 

Everything above can be achieved through creating individual dashboards. They can be structured by putting different cards of information on one frontend which gives a result customized view for each person. 

  • Personal notifications 

What about some modern notifications with customized messages? The Developer Portal might also support developers with such functionality. 

Let’s consider a scenario where the developer has a high-priority review and wants to get immediate notification when the Jenkins job passes, or the review is ready to be merged. It can be done by marking the review as a high priority in the Developer Portal and just waiting for notification. Maybe the project manager also wants such information for this review only? They all can mark interesting reviews and get customized notifications. 

You can see that the Developer Portal can help in a lot of different ways. It is worth noting that the name of it can be misleading – such a tool can help not only developers but also QA engineers, project managers, or others who are involved in the software development process. It can support many areas and give in a result better productivity, better predictability, or just make people more happy working in your company. 

While the Developer Portal can support companies by providing many helpful features, firstly it needs to be checked to see what areas are problematic. If you do not have a problem with the documentation, why care about such a feature? If your organization has already implemented dashboards that work well, you do not need such functionality from the Developer Portal. However, maybe people have problems with finding useful information. Or maybe with finding relations between software components? 

Such an analysis needs to be done first to start implementing the Developer Portal with the biggest return on investment. As RSC we can help you with this – let us find your most problematic areas, analyze how they can be resolved, and reach productivity that you never had.