

In most teams, the question is no longer "Do we need an internal developer portal?" but "Do we really want to run backstage ourselves?"
Backstage proved the internal developer portal (IDP) pattern, and it works. It gives you a flexible framework, plugins, and a central place for services and docs. It also gives you a long-term commitment: owning a React/TypeScript application, managing plugins, chasing upgrades, and justifying a dedicated platform squad to keep it all usable.
That's why there are Backstage alternatives like Harness IDP and managed Backstage services. It's also why so many platform teams are taking a long time to look at them before making a decision.
Backstage was created by Spotify to fix real problems with platform engineering, such as problems with onboarding, scattered documentation, unclear ownership, and not having clear paths for new services. There was a clear goal when Spotify made Backstage open source in 2020. The main value props are good: a software catalog, templates for new services, and a place to put all the tools you need to work together.
The problem is not the concept. It is the operating model. Backstage is a framework, not a product. If you adopt it, you are committing to:
Once Backstage moves beyond a proof of concept, it takes a lot of engineering work to keep it reliable, secure, and up to date. Many companies don't realize how much work it takes. At the same time, platforms like Harness are showing that you don't have to build everything yourself to get good results from a portal.
When you look at how Harness connects IDP to CI, CD, IaC Management, and AI-powered workflows, you start to see an alternate model: treat the portal as a product you adopt, then spend platform engineering energy on standards, golden paths, and self-service workflows instead of plumbing.
When you strip away branding, almost every Backstage alternative fits one of three patterns. The differences are in how much you own and how much you offload:
| Build (Self-Hosted Backstage) |
Hybrid (Managed Backstage) | Buy (Commercial IDP) | |
|---|---|---|---|
| You own | Everything: UI, plugins, infra, roadmap | Customization, plugin choices, catalog design | Standards, golden paths, workflows |
| Vendor owns | Nothing | Hosting, upgrades, security patches | Platform, upgrades, governance tooling, support |
| Engineering investment |
High (2–5+ dedicated engineers) | Medium (1–2 engineers for customization) | Low (configuration, not code) |
| Time to value | Months | Weeks to months | Weeks |
| Flexibility | Unlimited | High, within Backstage conventions | Moderate, within vendor abstractions |
| Governance & RBAC |
Build it yourself | Build or plugin-based | Built-in |
| Best for | Large orgs wanting full control | Teams standardized on Backstage who want less ops | Teams prioritizing speed, governance, and actionability |
What This Actually Means
You fork or deploy OSS Backstage, install the plugins you need, and host it yourself. Or you build your own internal portal from scratch. Either way, you now own:
Backstage gives you the most flexibility because you can add your own custom plugins, model your internal world however you want, and connect it to any tool. If you're willing to put a lot of money into it, that freedom is very powerful.
Where It Breaks Down
In practice, that freedom has a price:
This path could still work. If you run a very large organization and want to make the portal a core product, you need to have strong React/TypeScript and platform skills, and you really want to be able to customize it however you want, building on Backstage is a good idea. Just remember that you are not choosing a tool; you are hiring people to work on a long-term project.
What This Actually Means
Managed Backstage providers run and host Backstage for you. You still get the framework and everything that goes with it, but you don't have to fix Kubernetes manifests at 2 a.m. or investigate upstream patch releases.
Vendor responsibilities typically include:
You get "Backstage without the server babysitting."
Where The Trade-Offs Show Up
You also inherit Backstage's structural limits:
Hybrid works well if you have already standardized on Backstage concepts, want to keep the ecosystem, and simply refuse to run your own instance. If you're just starting out with IDPs and are still looking into things like golden paths, self-service workflows, and platform-managed scorecards, it might be helpful to compare hybrid Backstage to commercial IDPs that were made to be products from the start.
What This Actually Means
Commercial IDPs approach the space from the opposite angle. You do not start with a framework, you start with a product. You get a portal that ships with:
The main point that sets them apart is how well that portal is connected to the systems that your developers use every day. Some products act as a metadata hub, bringing together information from your current tools. Harness does things differently. The IDP is built right on top of a software delivery platform that already has CI, CD, IaC Management, Feature Flags, and more.
Why Teams Go This Route
Teams that choose commercial Backstage alternatives tend to prioritize:
You trade some of Backstage's absolute freedom for a more focused, maintainable platform. For most organizations, that is a win.
People often think that the difference is "Backstage is free; commercial IDPs are expensive." In reality, the choice is "Where do you want to spend?"
When you use open source, you save money but lose engineering capacity. With commercial IDPs like Harness, you do the opposite: you pay to keep developers focused on the platform and save time. A platform's main purpose is to serve the teams that build on it. Who does the hard work depends on whether you build or buy.
This is how it works in practice:
| Dimension | Open-Source Backstage | Commercial IDP (e.g., Harness) |
|---|---|---|
| Upfront cost | Free (no license fees) | Subscription or usage-based pricing |
| Engineering staffing | 2–5+ engineers dedicated at scale | Minimal—vendor handles core platform |
| Customization freedom | Unlimited—you own the code | Flexible within vendor abstractions |
| UX consistency | Drifts as teams extend the portal | Controlled by product design |
| AI/automation depth | Add-on or custom build | Native, grounded in delivery data |
| Vendor lock-in risk | Low (open source) | Medium (tied to platform ecosystem) |
| Long-term TCO (3–5 years) | High (hidden in headcount) | Predictable (visible in contract) |
Backstage is a solid choice if you explicitly want to own design, UX, and technical debt. Just be honest about how much that will cost over the next three to five years.
Commercial IDPs like Harness come with pre-made catalogs, scorecards, workflows, and governance that show you the best ways to do things. In short, it's ready to use right away. You get faster rollout of golden paths, self-service workflows, and environment management, as well as predictable roadmaps and vendor support.
The real question is what you want your platform team to do: shipping features in your portal framework, or defining and evolving the standards that drive better software delivery.
When compared to other Backstage options, Harness IDP is best understood as a platform-based choice rather than a separate portal. It runs on Backstage where it makes sense (for example, to use the plugin ecosystem), but it is packaged as a curated product that sits on top of the Harness Software Delivery Platform as a whole.
There are a few design principles stand out:
When you think about Backstage alternatives in terms of "How much of this work do we want to own?" and "Should our portal be a UI or a control plane?" Harness naturally fits into the group that sees the IDP as part of a connected delivery platform rather than as a separate piece of infrastructure.
A lot of teams say, "We'll start with Backstage, and if it gets too hard, we'll move to something else." That sounds safe on paper. In production, moving from Backstage gets harder over time.
Common points where things go wrong include:
The point isn't "never choose Backstage." The point is that if you do, you should think of it as a strategic choice, not an experiment you can easily undo in a year.
Whether you are comparing Backstage alone, Backstage in a managed form, or commercial platforms like Harness, use a lens that goes beyond feature checklists. These seven questions will help you cut through the noise.
If a solution cannot give you concrete answers here, it is not the right Backstage alternative for you.
Choosing among Backstage alternatives comes down to one question: what kind of work do you want your platform team to own?
Open source Backstage gives you maximum flexibility and maximum responsibility. Managed Backstage reduces ops burden but keeps you within Backstage's conventions. Commercial IDPs like Harness narrow the surface area you maintain and connect your portal directly to CI/CD, environments, and governance.
If you want fast time to value, built-in governance, and a portal that acts rather than just displays, connect with Harness.


At Harness, our mission has always been simple but ambitious: to enable every software engineering team in the world to deliver code reliably, efficiently, and quickly to their users, just like the world’s leading tech companies. As AI coding assistants accelerate application teams' ability to change code, traditional delivery processes are becoming a bottleneck, making DevOps excellence more important than ever. Today, the industry validated the critical nature of this work with a resounding vote of confidence.
We are incredibly honored to announce that TechStrong TV and DevOps.com have recognized Harness with three prestigious DevOps Dozen Awards.
While we are grateful for every accolade, this year’s wins are particularly special. They don’t just recognize individual features; they validate our complete vision for the future of software delivery, one that is platform-centric, AI-native, and developer-focused.
Here is a look at the categories Harness took home this year.
This is the big one. Winning Best End-to-End DevOps Platform is a testament to the shift we are seeing across the entire market. Organizations are moving away from fragmented, brittle toolchains of "point solutions" and rigid all-or-nothing platforms toward modular platforms that meet them where they are.
Modern engineering teams need more than just CI or CD in isolation. They need a comprehensive platform that offers a best-in-class modular approach. Whether it is accelerating builds with Continuous Integration, governing deployments with Continuous Delivery, or optimizing spend with Cloud Cost Management, the real magic happens when these modules work together.
This award reinforces that the Harness Platform—with its unified pipeline orchestration, automated governance, and shared intelligence—is the standard for end-to-end software delivery.
For the second year in a row, Harness has been named the Best Platform Engineering Solution.
Platform Engineering is no longer a "nice to have." It is a necessity for scaling innovation. The Harness Internal Developer Portal (IDP) is designed to solve the critical challenge of developer cognitive load. By providing golden paths and self-service capabilities with automated guardrails, we allow developers to focus on what they love: creating new capabilities.
Winning this award two years running proves that our commitment to the developer experience is resonating deeply with the industry.
Finally, we are thrilled to see our CEO and Co-founder, Jyoti Bansal, recognized as DevOps Industry Leader of the Year.
From founding AppDynamics to leading Harness, Jyoti has spent his career obsessed with solving the hardest problems in software. His vision for AI for Everything After Code is driving the industry forward, moving us from simple automation to true intelligent orchestration. This award recognizes not only his leadership at Harness but also his contributions to the DevOps community as a whole.
These awards from DevOps.com add to a year of incredible momentum, joining recent recognition from major analyst firms like Gartner and Forrester.
But we aren't slowing down. With our continued investment in AI agents, automated governance, and expanding our module ecosystem, we are just getting started.
To our customers, partners, and the Harness team: Thank you. These awards belong to you.


A developer once told me, half-joking and half-frustrated, “I spend more time waiting than coding.” It wasn’t the dramatic kind of waiting, like an hour-long debugging session or a blocked deployment at midnight. It was the everyday waiting that creeps into a team’s workflow. Waiting for a repository to be created. Waiting for infrastructure. Waiting for a ticket to move from “To Do” to “In Progress.” Waiting for someone to approve a routine task.

Image description: a stick-person cartoon of developers playing swords. The caption reads: “The #1 programmer excuse for legitimately slacking off: my code’s compiling.” Source: https://xkcd.com/303/
None of these delays are catastrophic on their own, but they accumulate. Days turn into weeks. Friction becomes normal. Productivity quietly drops. And everyone just accepts it because “that’s how things work.”
This slow, ticket-driven model is what many teams refer to as Ticket Ops. It is one of the biggest obstacles to engineering velocity, but it often goes unnoticed because it’s simply the way things have always been.
But platform engineering teams are starting to ask a different question: What if developers didn’t have to wait at all?
That idea—a world where developers can move quickly without depending on a chain of manual steps—is the foundation of developer self-service. And inside the Harness Internal Developer Portal (IDP), that promise becomes real through Workflows.
Workflows aren’t just buttons or forms. They’re guided, automated pathways that help engineers onboard services, launch environments, and complete Day-2 tasks with confidence. They transform the daily experience of building software, reducing developer friction and helping organizations accelerate software delivery in a sustainable, scalable way.
To understand why Workflows matter, it helps to picture the start of a typical engineering task.
Imagine a developer preparing to build a new microservice. Before they write a single line of code, there’s a list of tasks to complete. They need a repo. They need pipelines. They need security baselines. They need the service registered in the catalog. They might need a Jira or ServiceNow ticket. They need to understand compliance requirements and infrastructure choices.
It’s not unusual for developers to spend several days just assembling the basics.
And even when companies use templates or documentation, reality rarely matches the ideal. Docs drift out of date. Scripts behave differently on different machines. Best practices live in people’s heads. Engineers copy something that “worked last time,” even if it isn’t correct anymore.
This is where Workflows step in. Instead of asking developers to manually navigate dozens of decisions and systems, Harness IDP gives them a clear, consistent way forward.
Imagine that same developer opening the Internal Developer Portal.
Instead of tackling a pile of steps, they see a simple entry point: Create a new service.
They click. They answer a few straightforward questions. Then they run the workflow.
What happens next feels almost magical:
A repository appears with a secure boilerplate. Pipelines are created automatically. Scorecards evaluate whether the service meets standards. The service registers itself in the catalog. Tickets are opened if required. Notifications go out. An environment may even be created so the developer can test changes immediately.
The developer gets a working service in minutes.
The platform team knows it was built the right way.
And the company gains a golden path that works the same every time.
This is the heart of Harness IDP Workflows: transforming complex, multistep engineering efforts into a guided, repeatable flow that improves developer productivity and streamlines the developer workflow.
(If you'd like to try this type of onboarding workflow, you can follow this tutorial.)
Although the developer experience is simple, the underlying structure is powerful. Each workflow is defined in a YAML file stored in Git, typically called workflow.yaml. It contains three essential parts.
The first part defines the inputs. These are the fields the developer fills in when starting the workflow. The second part describes the backend actions that run behind the scenes—everything from provisioning infrastructure to running pipelines or creating tickets. The third part outlines the outputs, such as links to environments, service URLs, or test results.
Because everything lives in Git, platform teams can review changes, maintain version control, and collaborate the same way they would for code. And when they are ready, they register the workflow inside Harness IDP so it becomes available for everyone.
If you want to explore the full YAML model and configuration options, check out our documentation. And, you can also customize how Workflows appear in the portal.
The term “golden path” gets used a lot in platform engineering. In many organizations, it refers to a recommended approach documented somewhere in Confluence or Notion. But documentation alone doesn’t guarantee consistency. People interpret instructions differently. They skip steps. They fall back on what they already know.
Harness IDP turns golden paths into the way things actually get done. Because Workflows are automated and centrally defined, every developer follows the same standards without needing to memorize anything. Security guidelines, IaC best practices, compliance rules, and architectural patterns are all baked into the workflow itself.
Developers get a smooth, intuitive experience.
Platform teams get consistency and governance.
Leaders get confidence that the system is operating safely.
This shift is one of the biggest reasons companies adopt an IDP.
Service creation is only one example of where Workflows shine. Companies also use them for operational tasks like restarting services, running scripts, creating feature environments, performing database maintenance, or handling access requests.
A workflow might deploy Terraform to provision infrastructure, call an API to update a SaaS system, or notify teams in Slack. Another workflow might help testers spin up preview environments whenever a pull request is opened.
These flows often replace a long history of manual steps that used to depend on one or two specialists. Instead of being bottlenecks, those specialists become the people who automate the workflow once, then support every developer who uses it.
This is how Workflows help organizations reduce developer friction and accelerate software delivery at scale.
One of the most exciting areas where Workflows are becoming essential is environment creation. Developers often wait days for a new environment, especially in companies with heavy compliance requirements or limited infrastructure resources.
Beginning in January, Harness will introduce Environment Management, which extends self-service into the world of environments. With EM, developers will be able to spin up full-stack environments on demand, generate preview environments for every pull request, and automatically clean them up to control costs.
Workflows serve as the perfect front door for this capability. They guide developers through the process, enforce policy, trigger the right automation, and provide consistent output. Environment Management will handle the heavy lifting behind the scenes.
Self-service infrastructure becomes a natural extension of the platform, rather than a new system developers must learn.
Every engineering organization wants the same outcome. They want developers to move quickly, teams to follow best practices, and governance without slowing anyone down.
Harness IDP Workflows make this balance possible. They simplify the everyday experience of building software while giving developers intuitive, reliable paths to get work done. They help platform engineering teams scale their expertise without becoming blockers. And they help companies create sustainable, intelligent patterns that improve engineering health over time.
Learn more: What Is a Developer Platform
.png)
.png)
Joining a new engineering team can be exciting, but it can also be overwhelming. You spend the first few days figuring out what each service does, where documentation lives, and who owns what. Even experienced engineers lose time switching between tools, looking for context, and waiting on answers.
Internal Developer Portals (IDPs) were designed to fix that problem. They centralize information about services, documentation, environments, and workflows so developers can work from one place.
The challenge is that most portals stop there. They display data but don’t help developers act on it. That’s where the Harness IDP Knowledge Agent comes in.
The Knowledge Agent lives inside the Harness IDP and serves as an AI-powered teammate. It helps developers find the information they need, understand how systems work, and take action faster. You can ask questions like, “Who owns the authentication service?” or “How can I improve my score?” and get relevant, trustworthy answers in seconds.
The Harness & InfoQ webinar, Architecting the AI-Powered IDP, explored how developer time is really spent today. Research from Gartner shows that only about 30-40% of engineering time goes toward writing code. The rest, nearly 70%, is spent testing, securing, deploying, and maintaining systems.
That imbalance has real costs. Manual approvals, disconnected tools, and outdated scripts make software delivery slower and more expensive. Developers end up managing complexity instead of building products.
AI coding assistants promise efficiency, but they’re also widening the gap. According to the 2025 DORA State of AI-Assisted Software Development Report, AI improves individual productivity by 19%. However, organizational throughput improves only 3%, and delivery stability actually drops 9%.
Basically, this shows that teams are producing more code than ever, but delivery systems haven’t evolved to handle the extra load. The result is a growing delivery bottleneck, with more pipelines to maintain, more configurations to fix, and more friction across the software lifecycle.
The same DORA report points to a clear solution. Teams with strong, automated platforms gain both speed and stability from AI. Teams with scattered tools and manual workflows see the opposite, and AI magnifies inefficiency instead of solving it.
Harness research confirms this trend. Companies with mature continuous delivery practices are twice as likely to report faster release cadences when using AI. The takeaway is simple: platform quality determines whether AI helps or hurts.
A strong platform, built on reusable pipelines, consistent templates, and solid governance, is what allows AI to deliver real business value. That’s exactly what the Harness IDP Knowledge Agent helps teams achieve.
The Knowledge Agent acts as the voice of your platform. It understands your services, pipelines, environments, and scorecards, and it uses that context to help you make faster, better decisions.
Ask about a service, and it tells you what it does, who owns it, when it was last deployed, and how it’s performing. Ask how to raise your service score, and it recommends specific steps based on your team’s best practices.
Instead of switching between dashboards, tools, and tickets, developers can ask questions right in the portal and get instant, actionable answers. It’s like having an expert teammate available whenever you need one.
The Knowledge Agent is powered by Harness AI and built on a software delivery knowledge graph, which is a connected data layer that links information from across your engineering ecosystem.
The graph brings together build data, deployment events, test results, security scans, cloud cost reports, and monitoring insights. This context allows the AI to understand relationships between systems and services rather than pulling information in isolation.
Ask, “Where are the docs for this service?” and it searches internal wikis, TechDocs, README files, and Harness IDP documentation to find the most relevant information.
Ask, “Create a new Kubernetes environment in AWS,” and it identifies the right workflow, fills in parameters, and executes it automatically.
This combination of intelligence and automation transforms the Harness IDP from a static catalog into a dynamic platform that understands your organization and helps it operate more efficiently.
Many AI tools can summarize text or surface data, but the Harness Knowledge Agent is built directly into the Harness platform. That means it operates on live, trusted data from your services, pipelines, and environments.
It also respects your security and access controls. Developers see only what they’re authorized to view, and every answer includes transparent reasoning so teams understand how conclusions were reached.
This balance of accuracy, visibility, and explainability builds confidence. It’s not just an assistant, it’s a reliable partner that helps teams move faster with control and consistency.
Developer portals typically evolve through three stages:
The Knowledge Agent powers that final stage. It connects a knowledge graph, AI-driven workflows, and autonomous delivery into one intelligent interface.
With it, developers can ask for a new service with a database, and the portal handles everything, like provisioning infrastructure, configuring pipelines, applying governance, and verifying deployment health.
This evolution transforms a portal from a reference point into an active engine that drives real work.
Imagine you’re new to a team and need to learn about the “authentication-service.” You ask the Knowledge Agent to explain it. It shows what the service does, who owns it, when it was last deployed, and its performance score.
Next, you ask how to improve reliability. The Agent reviews your scorecards and suggests adding monitoring, improving test coverage, and adjusting deployment approvals.
Finally, you ask it to start the workflow for monitoring. It executes the right pipeline, provisions the necessary resources, and reports success.
A process that might have taken hours now happens in minutes, without switching tools or asking for help.
AI has changed how teams build software, but it hasn’t changed how they deliver it. Code creation is faster, yet delivery processes remain slow and fragmented.
Intelligent IDPs close that gap by connecting systems, surfacing insights, and turning context into action. They bridge development and delivery, reducing manual steps and helping teams ship faster and with confidence.
The Harness Knowledge Agent is the next step in that journey. It combines the power of automation with the intelligence of AI to make developer platforms more proactive, transparent, and efficient.
For developers, that means fewer roadblocks and faster onboarding. For platform teams, it means better governance and a scalable model for supporting the organization. For engineering leaders, it means seeing real ROI from AI investments.
The Harness Knowledge Agent is available now in Harness IDP for anyone who wants to try it.
If you already use Harness IDP, contact your account team to enable it. If not, you can request a demo to see how it works in action.
And to learn more about how platform engineering and AI come together, read Platform Engineering: Beyond the Trough of Disillusionment and Industry Reports Agree: DevOps is the Key to Unlocking AI’s Potential.
Harness is helping teams build the next generation of intelligent developer portals that are powered by AI, designed for scale, and ready for real-world engineering challenges. The Knowledge Agent is a first step in that evolution.


If you've been following industry conversations recently, you've likely seen Mark O'Neill's pointed LinkedIn post referencing Jennifer Riggins' article in The New Stack, suggesting platform engineering is headed for Gartner's notorious "Trough of Disillusionment." The Gartner Hype Cycle graphic prominently displays platform engineering perched at that precarious precipice, with a big red arrow pointing downward.

As someone who's been in the trenches with teams adopting platform engineering practices, I can't entirely disagree with this assessment—but I believe it represents a necessary and healthy evolution rather than a death knell.
The challenges highlighted by industry experts resonate with what we're seeing across organizations:
These challenges aren't symptoms of a failing concept—they're growing pains of a maturing practice.
What separates successful platform initiatives from those heading toward disillusionment? In our experience working with hundreds of engineering organizations at Harness, the answer lies in the mindset shift from platform-as-technology to platform-as-product.
This shift requires three fundamental changes:
ROI calculations for platform engineering shouldn't be rocket science. When we work with customers implementing Harness Platform, we focus on concrete metrics that translate directly to business impact:
These metrics create a clear line between platform adoption and business outcomes, making the value proposition obvious to leadership.
Industry standard metrics like DORA and SPACE can also provide good framework for what to measure. In both cases, you are generally not measuing direct business impact but leading indicators of business impact. Platform teams need to have executive buy-in before measuring that this leap from leading indicator to business impact is going to hit the mark for the people approving budgets.
The "build versus buy" debate misses the point entirely. The most successful platform teams we work with have embraced composability—thoughtfully selecting best-of-breed tools and integrating them into a coherent developer experience.
Harness Platform was designed with this reality in mind. Rather than forcing teams to build everything from scratch or adopt a monolithic solution, our modular approach allows teams to:
This approach dramatically reduces time-to-value while still providing the flexibility engineers crave.
One of the most revealing statements from the panel discussion was Leena Mooneeram's observation: "We're incredibly lucky. We work in the same company as our customers."
Yet many platform teams fail to leverage this proximity advantage. They build platforms in isolation, then wonder why adoption lags. Platform teams fall into one of the classic traps those of us who build tools for engineers are tempted with - "I'm a developer, I know what developers want." Famous last words. Do the hard work of spending time with your teams and seeing what they really need from your platform.
The most successful platform initiatives treat internal developers as true customers:
Every transformative movement in software engineering has faced its moment of disillusionment. DevOps experienced the same trajectory before emerging as an established, mainstream practice.
At Harness, we believe platform engineering is following this same pattern. The trough represents a necessary correction—a moment for the industry to move beyond hype and establish sustainable practices.
As organizations recalibrate their approach, we're already seeing the emergence of platform engineering 2.0:
For organizations navigating this transition, Harness offers a proven path forward. Our platform approach enables teams to:
Yes, platform engineering is likely entering the trough of disillusionment. But this moment of correction is setting the stage for something more valuable and sustainable. We have done the early trailblazing and found that platform engineering really works. The success stories are too plentiful to ignore. However, we have also seen enough stumbles that we are learning to be a bit more careful and disciplined in our approach. We know where the pitfalls are. What a great time time.
By focusing on business outcomes, embracing composability, and truly centering developer experience, platform engineering will emerge from this trough stronger and more impactful than ever.
The organizations that use this moment as an opportunity to refine their approach—rather than abandoning their platform efforts—will be the ones who realize the true promise of platform engineering: delivering business value at the speed of software.


As organizations increasingly adopt microservices and DevOps practices, managing the health of services and tracking engineering initiatives has become a crucial challenge. While spreadsheets have long been the go-to tool for tracking and monitoring, their limitations become glaring as teams scale and the complexity of systems grows. Enter scorecards in Internal Developer Portals (IDPs)—a powerful alternative that revolutionizes how service health and initiatives are monitored.
Here’s why you should consider scorecards in your IDP instead of sticking with spreadsheets:

In modern engineering environments, multiple teams often own various services. Scorecards in an IDP provide centralized and consistent visibility into service health, making it easy for every team member to see relevant metrics and statuses.
Spreadsheets, on the other hand, often get siloed, requiring manual sharing and updates. With an IDP, you ensure that every team operates from the same source of truth without the overhead of maintaining shared links and permissions.
Scorecards are often integrated directly with monitoring tools, CI/CD pipelines, and incident management systems. This ensures real-time updates, reflecting the current health of your services and progress on initiatives.
In contrast, spreadsheets are static and rely on manual updates, making them prone to delays, inaccuracies, and inconsistencies. A stale spreadsheet can lead to poor decision-making during critical incidents.
Scorecards leverage automation to populate data, track progress, and highlight anomalies. This reduces the risk of human error, such as incorrect data entry or forgetting to update a field—common pitfalls with spreadsheets.
For instance, a scorecard can automatically display the uptime of a service or the percentage completion of an initiative based on real-time inputs from your tools, freeing engineers to focus on solving problems rather than updating records.
Scorecards in an IDP provide a collaborative environment, allowing teams to add comments, links, or notes alongside metrics. They also enable drill-down capabilities for context—like linking directly to monitoring dashboards or incident logs.
Spreadsheets are limited in this regard. Adding contextual information is cumbersome, and navigating large, complex spreadsheets can become a frustrating experience for teams.
IDP scorecards can be tailored to display metrics that matter most to your organization, such as service-level objectives (SLOs), deployment frequency, or incident resolution times. They often allow customizable dashboards, letting teams focus on their priorities.
Spreadsheets lack dynamic visualization capabilities, requiring manual effort to create charts or dashboards that may still fall short in conveying actionable insights.

As organizations grow, the number of services and metrics they need to track increases exponentially. Scorecards scale seamlessly with your IDP, integrating with existing tools like Harness, Kubernetes, Jenkins, Datadog, or PagerDuty.
Spreadsheets struggle with scalability. Managing hundreds of rows and columns across multiple sheets can lead to performance issues and confusion, especially as teams change or expand.
Modern IDPs with automated scorecards can help show when metrics breach thresholds or when initiatives fall behind. They can help to surface trends and historical data to guide long-term decision-making.
While spreadsheets can store historical data, identifying trends can require manual intervention or complex scripts that are difficult to maintain.

Scorecards enhance developer experience by providing a one-stop shop for metrics, insights, and action items within the same platform they use for other engineering tasks. This reduces context-switching and improves efficiency.
Spreadsheets, being external tools, require developers to toggle between platforms, disrupting their workflow and reducing productivity.
Spreadsheets served their purpose in the past, but as engineering teams grow and systems become more complex, their limitations become a bottleneck. Scorecards in an Internal Developer Portal offer a scalable, real-time, and collaborative solution tailored to the needs of modern software teams.
By adopting scorecards, you can empower your teams to focus on building and maintaining resilient systems while staying aligned on strategic initiatives. Ditch the spreadsheets and embrace the future of service health tracking—your developers (and your bottom line) will thank you.
To see a brief video about Scorecards in Harness IDP, Click Here: YouTube !
Read the docs or Harness IDP here: Internal Developer Portal !
Ready to take your service health tracking to the next level? Click Here to explore how Harness Internal Developer Portal with scorecards can streamline your operations!


With the rise of complex, distributed software architectures and the shift toward faster, more reliable releases, internal developer portals (IDPs) have become invaluable. These portals centralize tools, services, documentation, and processes, improving productivity, standardization, and development velocity across teams. However, not all IDPs are created equal, and choosing or optimizing the right one requires a strategic approach. Here’s a guide on how to effectively evaluate an internal developer portal to ensure it meets your organization’s needs.
Before you dive into the specifics, take time to outline why your organization needs an internal developer portal. Some common goals might include:
Once you have a list of clear goals, create specific criteria based on these needs. For instance, if developer onboarding is a primary focus, your IDP should emphasize accessible documentation, easy-to-navigate interfaces, and self-service functionalities.
A key aspect of any successful IDP is its usability and the experience it provides developers. Here are some factors to consider:
An effective way to measure usability is by conducting usability tests or gathering feedback from developers during trial periods. Tracking usage metrics such as page visits, search queries, and navigation patterns can also offer insight into the portal’s intuitiveness and accessibility.
One of the primary functions of an IDP is to bring together the tools, services, and workflows developers need. Therefore, evaluate the portal's integration capabilities carefully:
A well-integrated IDP reduces the need to switch between multiple tools, helping developers stay in their flow and increasing overall productivity.
Empowering developers to manage and provision resources themselves can significantly reduce dependencies on operations teams. Evaluate whether the IDP provides:
IDPs centralize a lot of information, from documentation and code repositories to operational dashboards. To prevent information overload, the portal must prioritize effective search and discoverability:
Tracking the impact and usage of an IDP is essential for continuous improvement. Look for portals that provide built-in analytics to assess engagement, identify bottlenecks, and monitor performance:
This data helps you measure whether the portal meets its intended goals and provides a basis for iterative improvements.
Consider your organization’s growth trajectory and assess whether the IDP can scale accordingly. Important factors to evaluate include:
Since an IDP often integrates with various internal systems, security should be a priority. Consider these factors:
Evaluating an internal developer portal is not a one-time task. After the initial setup, it’s crucial to establish a process for continuous improvement based on developer feedback, usage data, and evolving organizational needs. By regularly revisiting your criteria and adjusting as necessary, you can ensure that your IDP continues to enhance productivity, standardize processes, and empower developers to do their best work.
An internal developer portal is an investment in your developer experience, but with thoughtful evaluation and ongoing refinement, it can transform how your teams build and deliver software.
For more information about Harness IDP, click Harness IDP here
Read the docs for Harness IDP
Sign up to get a demo of the Harness IDP


In modern software development, Internal Developer Portals (IDPs) have emerged as a powerful tool for centralizing resources, streamlining processes, and enhancing collaboration across teams. They are a critical part of enabling developer productivity, reducing bottlenecks, and fostering a culture of autonomy. Building an effective IDP can transform how teams operate, but it requires careful planning and execution. Our last blog covered some pitfalls you may experience, and how to avoid them. Below are five best practices to ensure your IDP delivers maximum value to your organization.
The primary users of an internal developer portal are developers, so Developer Experience (DX) should be at the heart of your design. An IDP should be intuitive, fast, and easy to navigate. By focusing on DX, you reduce the friction developers face when trying to find services, documentation, and tools. It should be persona-driven. Here’s how to enhance DX in your IDP:
One of the core functions of an IDP is to centralize tools, services, and processes. However, it’s important that this centralization doesn’t result in a fragmented experience. Developers use various tools (CI/CD pipelines, version control systems, cloud services, monitoring tools, etc.) throughout the software development lifecycle. Your IDP should offer seamless integration across all these platforms to streamline the developer workflow.
The ability to quickly discover services, tools, and documentation is crucial in an IDP. Developers often waste valuable time searching for the right resources, and poor discoverability leads to frustration. A successful IDP allows developers to easily search, explore, and understand available resources. Learn about the Catalog Ingestion API’s in the Harness IDP : Catalog Ingestion APIs.
An IDP isn’t just a tool repository—it’s also a collaboration hub. Developers across teams should be able to share insights, document solutions, and contribute to a collective knowledge base. This improves communication between teams and helps avoid siloed knowledge.
Automation is key to improving developer efficiency, and an IDP can be a powerful vehicle for that. Automating repetitive tasks—like environment provisioning, testing, or deployment—frees developers to focus on high-value work. Additionally, strong governance mechanisms ensure that tools and processes follow best practices and maintain consistency across the organization.
Building an effective Internal Developer Portal is an ongoing effort that requires balancing usability, integration, automation, and collaboration. By focusing on these five best practices—prioritizing Developer Experience, integrating tools seamlessly, enabling discoverability, fostering collaboration, and emphasizing automation with governance—you can create a portal that truly enhances developer productivity and drives innovation.
Your IDP should evolve alongside your development practices, becoming a central hub that accelerates and simplifies the way your teams work. With the right approach, it becomes much more than a tool—it becomes an enabler of developer success.
To find out more about Harness IDP, and request a demo, be sure to click here
.webp)
.webp)
Harness believes in the power of Backstage as the go-to open source framework for powering Internal Developer Portals. With its robust plugin model and strong presence in the market, Backstage has proven to be a valuable tool for many organizations. However, as a framework rather than a ready-to-use solution, Backstage poses many adoption challenges in terms of completeness and maintenance. This is where Harness steps in, offering a full-featured Internal Developer Portal product, an enterprise-grade solution built on top of Backstage to address these pain points and elevate the developer experience at a significantly faster pace than self-managed Backstage.
While Backstage offers great potential as a flexible framework for Developer Platforms, getting it up and running smoothly isn't always easy. It's not like installing a ready-made solution; instead, it needs careful setup to match what your developers need. Its strength lies in its plugin system, which helps solve developers' problems, forming the core of a good Developer Portal.
But even with its strengths, customizing Backstage to fit your developers' exact needs can be tough. Making a Developer Portal that suits your team might mean lots of coding work, especially for making user interfaces in React and typescript. If your team doesn't have skilled DevOps engineers or experienced front-end developers with React expertise, you might find it hard to overcome these challenges.
Also, developing such a complex product requires a skilled team which requires significant investment. To use Backstage well, you need dedicated DevOps engineers, senior developers, and a good product owner. Without them, you might struggle to make the most of Backstage as your Developer Portal solution. Harness IDP takes away those building parts from your side and offers a latest version of the backstage with enterprise grade features.
One of the key areas where Harness adds value is in workflow automation, particularly with the Scaffolder functionality. While Backstage provides basic automation for component registration, Harness IDP extends this by offering more generalized developer automation. Leveraging the Pipeline automation workflow engine, developers can enjoy self-service capabilities, reducing wait times and improving time to market.


Managing Backstage can be cumbersome, requiring manual editing of files and tracking changes. Harness IDP simplifies this process by handling hosting, upgrading, and patching, while providing an intuitive administrative interface. This alleviates the administrative burden and allows platform teams to focus on higher-value tasks.

Harness IDP comes equipped with robust Role-Based Access Control (RBAC) out of the box and seamlessly integrates with Single Sign-On (SSO) providers like Okta. Access to automation can be finely governed by permissions, ensuring security and compliance without the need for extensive configuration.

As part of the Harness IDP solution, Scorecards offer a unique capability to track organizational initiatives and progress across teams and services. Whether it's achieving specific test coverage targets or migrating to newer versions, Scorecards provide visibility and accountability.

Unlike loading every community plugin into the catalog, Harness IDP takes a cautious approach. Community plugins undergo rigorous review before being made available, ensuring safety and reliability for users. While this may introduce slight delays for less popular plugins, it ultimately prioritizes security.
While users retain a significant degree of customization power, Harness IDP ensures a balance between flexibility and stability. Unlike running a completely open-source project where any change is possible, the enterprise solution offers a curated environment for efficient development without compromising stability.
Harness' commitment is clear: to provide the latest features of Backstage alongside a superior administrative experience and innovative features that empower developers. By bridging the gap between Backstage's framework and enterprise needs, Harness IDP delivers a comprehensive solution for seamless development experiences.
Checkout the Latest IDP Update
Learn How Internal Developer Portals Boost Team Collaboration


Software development is ever-changing, and so are the tools and methodologies developers use. While microservices are the recent buzz and discussions on mono vs polyrepos are ongoing, monorepos have been a staple for a long time. These monolithic repositories, which house code for multiple projects in a single location, have their merits. They simplify dependency management, make code reviews efficient, and offer a unified versioning system.
However, the rise of Cloud Native tools and technologies has shifted the focus towards microservices, influencing tools like Backstage. Backstage, an open-source developer portal, has become a favorite for many organizations, especially those leaning towards microservices. But what about those still using or transitioning from monorepos?

Monorepos, while beneficial in many ways, come with their set of problems for backstage/Internal Developer Portal use case:
Plugins: Tools like Backstage have plugins, such as GitHub insights, that are designed with the assumption that a single repo corresponds to a single software component. In a monorepo setup, this can lead to inaccurate results, as multiple components might reside in the same repository.
Here's where the Harness Internal Developer Portal comes in. While it's true that our primary design has been microservice-first, and monorepos might seem like an afterthought, the IDP is equipped to handle both. The Harness Developer Portal is versatile enough to cater to both microservices and monorepos, ensuring no organization is left behind in their development journey.
This Harness Internal Developer Portal aims to enable organizations to handle monorepos as efficiently as microservices, especially given the challenges they present. Here's How:
In conclusion, monorepos offer a flexible and efficient approach to software development. With the ability to place YAML definitions anywhere, keep documentation organized, streamline service onboarding, and have precise path-aware checks, tools like Harness Internal Developer Portal make managing monorepos simpler and more effective. Whether you're a large enterprise or a growing startup, embracing these advantages can significantly enhance your development workflow.
Try out Harness Internal Developer Portal (IDP), we've got a wealth of resources to help you dive deeper. Please reach out to us for a demo. For a comprehensive understanding, our release blogs detail the latest features and updates. And if you're more of a visual learner, our video tutorials, and documentation offer step-by-step guides to get you started. Dive in and discover the transformative power of Harness IDP!


Harness Platform Continues to Expand to Address Key Customer Needs in Modern Software Delivery
San Francisco– Sept 21, 2023– At the {unscripted} conference, Harness, the Modern Software Delivery Platform® company, today announced four new product modules on the Harness platform. Each module is aimed at advancing the state of software delivery and developer experience, and includes Harness Code Repository, Harness Internal Developer Portal, Harness Infrastructure as Code Management, Harness Software Supply Chain Assurance.
Harness Code Repository
Harness Code Repository is a premium module based on open source GitnessTM (launched today) and tailored to meet the demands of enterprise teams and organizations. Gitness is a developer-friendly, open source Git platform created to address common obstacles in traditional software development workflows. Read more in the Gitness press release here. Harness Code Repository provides additional enhanced features and capabilities for Gitness, including:
Harness Code Repository will be available in beta next month.
Harness Internal Developer Portal (IDP)
With the rapidly emerging trend of Platform Engineering teams who seek to streamline developer experience for their organizations, developer portals are becoming a “must-have” for large engineering organizations. According to Gartner®, “By 2025, 75% of organizations with platform teams will provide self-service developer portals to improve developer experience and accelerate product innovation.” 1
Answering that demand from Harness customers, the Harness Internal Developer Portal (IDP) helps organizations accelerate new service onboarding, simplifying the often complex and time-consuming process of setting up infrastructure, configuring frameworks, establishing CI/CD pipelines, and more. Harness IDP is built on the Backstage.io platform, providing critical governance features out of the box and a simplified management experience.
Harness IDP includes:
The result is that developers spend less time being blocked and more time innovating. Visit harness.io/products/internal-developer-portal to learn more.
Harness Infrastructure as Code Management (IaCM)
Companies are using Infrastructure as Code (IaC) to define infrastructure requirements, configurations, and dependencies, and to manage resources in a more efficient and repeatable way. However, customers are still finding that most IaC solutions are labor intensive, create errors, and come with limited visibility and guardrails. Harness Infrastructure as Code Management (IaCM) addresses these challenges and adds automation and security.
Harness IaCM provides:
Harness IaCM helps organizations achieve the benefits of self-service infrastructure management, mitigate risks associated with manual processes, and optimize operational efficiency, resulting in more secure, compliant, and efficient infrastructure management. Get started with Harness IaCM today at harness.io/products/infrastructure-as-code-management.
Harness Software Supply Chain Assurance
Modern applications are being built with an exponentially growing number of open source components, each of which introduces new vulnerabilities that can put the application’s consumers at risk. For these reasons, the software supply chain has become the focus of cyberattacks that are increasing in both number and sophistication. According to Gartner, “By 2025, 45% of organizations worldwide will have experienced attacks on their software supply chains, a three-fold increase from 2021.” 2
Recent supply chain attacks, such as log4j and SolarWinds, underscore the importance of open source governance and ensuring software artifact integrity in alignment with standards like Supply Chain Levels for Software Artifacts (SLSA). In the United States, Executive Order 14028 mandates SBOMs, provenance verification, policy enforcement, and rapid zero-day vulnerability response to enhance supply chain security.
The Harness Software Supply Chain Assurance (SSCA) module comprehensively addresses these requirements by providing:
Learn more about Harness SSCA at harness.io/products/software-supply-chain-assurance.
"The four new modules we are launching today represent a significant leap forward on our mission to enhance efficiency, foster collaboration, and fortify security throughout the software delivery lifecycle,” said Jyoti Bansal, CEO and cofounder of Harness. “These new innovations are the latest way we are providing developers and organizations with the tools and capabilities to help them achieve their software development goals.”
Harness additionally announced two new industry-wide communities:
1 Gartner, Innovation Insight for Internal Developer Portals, By Manjunath Bhat, Mark O’Neill, Oleksandr Matvitskyy, Published 1 February 2022.
2Gartner, Emerging Tech: A Software Bill of Materials Is Critical to Software Supply Chain Management by Mark Driver, Published 6 September 2022.
GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.
About Harness
Harness is the leading end-to-end platform for complete software delivery. It provides a simple, safe, and secure way for engineering and DevOps teams to release applications into production. Harness uses machine learning to detect the quality of deployments and automatically roll back failed ones, saving time and reducing the need for custom scripting and manual oversight, giving engineers their weekends back. Harness is based in San Francisco. Please visit www.harness.io to learn more.


Note: Harness Internal Developer Portal has graduated from Beta to Public Preview and then GA. Please see the more recent announcement.
In October 2022, when we launched the Backstage-Harness integration for our customers - we started talking to customers who were building their Internal Developer Portal on their own. Months into their journey, many of them complained about the struggles a Platform Engineering team goes through when building an IDP ground up which also includes self managing the hosting and operations aspects. While the trend suggests that IDPs will be everywhere, we couldn’t ignore the challenges our customers were facing in this journey. A successful IDP requires an investment of 3-5 engineers to get an early Proof of Concept, even when using a popular open source project like Backstage. It takes significant effort to set up basic enterprise features like service onboarding pipeline, user and group management, access control, secrets management, audit trails, and more. With Harness IDP, these features are a core part of our platform and are shipped out of the box.
Today, we are proud to go Beta with a handful of customers who need an IDP but find it challenging, costly and time consuming to manage it themselves or find a good alternative. Our IDP is powered by Backstage, the de-facto platform for building developer portals. We want to thank the community for building the software and we are committed to upstream contributions as we move forward.
But let’s back up a second, what is an IDP really? What problems does it solve? And what features does Harness IDP have?
Let’s start with the problems. The pain starts on day 1 with developer onboarding where it takes too much time and too many tickets to have developers commit, build, test code while also learning the process to get their features to production. It doesn’t get any easier even for more experienced engineers. In today’s cloud-based, decentralized, microservices environments, it’s challenging to manually track all software dependencies and things that need to happen every time changes need to be rolled out from dev-to-test-to-prod. Most organizations use a complex collection of infrastructure (cloud VM, Kubernetes, databases and more), frameworks (code, API, serverless and more) and tools (CI/CD, security scanners, monitoring and more) across different layers of the software stack. This internal maze of technologies creates unnecessary overhead, duplicates effort and hurts developer productivity. As a result, developers end up doing nonessential work to manage the cognitive overhead. Developer productivity and happiness requires removing roadblocks, and tool complexity is one of those roadblocks.
Now let’s take a look at how we are planning to solve these problems using Harness IDP.

How much time does it take for a developer in your company to create a new service? We have heard various answers from days, weeks to months. Lack of automation and standards result in fragmentation of technology choices. Inter-team dependencies make it really difficult to innovate fast.
In Harness IDP, as a developer, you can create a new backend service, API, or a website by submitting a few details as configured by your platform engineering. On the other hand, as a platform engineer, you can orchestrate the onboarding of services by creating pipelines in the Harness Pipeline Studio.
Developers focus on what they do best, which is writing features, while platform engineers focus on creating software templates, automating processes, and enforcing standards.


Imagine a world where you wake up in the morning, get to a single page which can tell you everything you need to know about your running software - its builds, deployments, alerts, errors, etc. And if you want to use a service owned by another team, you get to see its dependencies, documentation, API reference, owner information and much more!
With Harness IDP, all your technical documentation written in markdown is made available right alongside the software homepage in the catalog. The docs-like-code (https://www.docslikecode.com) approach ensures that docs are treated just like code, they live alongside the code and are updated in the same Pull Request by engineers. It also helps other developers find the documentation without going anywhere.

And with the Search functionality available not only on documentation, but across all the software components you have registered, you can quickly find what you need. This is so much better than “rumor-driven-development” isn’t it? Usually that involves asking a question on the #engineering-help channel and waiting for the handful few to notice and answer.


The number one reason Backstage is the best developer portal platform out there is its plugin architecture. There are hundreds of plugins available in the marketplace which integrate Backstage with third party providers and enhance the portal. We have built our own plugins and integrated with a curated list of Backstage plugins which you can enable and use.
Harness IDP is currently available to a limited set of customers. We want to work closely with our customers and evolve in more use-cases suited for a Developer Portal. To get started, send an email to idp-interest@harness.io for a demo and we’ll get you started. To learn more, checkout the documentation at developer hub.
Checkout Harness Internal Developer Portal
Learn more: Developer Portal Scalability Best Practices, Internal Developer Platform vs Internal Developer Portal, Effective governance strategies for internal developer portals