Crafting an effective RFP for an internal developer portal (IDP) is a critical step in modernizing your engineering organization. The process by which you get the information you need to make the right choice is just as, if not even more, important.
At this stage, engineering leaders take pen to paper and start the painful process of building a request for proposal (RFP), the first major step in internal dev portal procurement. But too often, the process gets bogged down in an endless checklist of features that loses sight of the one thing that matters: business impact. An IDP that isn't directly tied to a strategic business goal is just another tool. But an IDP built to solve a single, critical initiative becomes the foundation for engineering excellence.
This guide is a blueprint that shows you how to build an RFP for an internal developer portal, focusing on goals over features. It provides a framework to not only gain visibility into your engineering ecosystem, but to drive meaningful, measurable change.
The hidden costs of a disconnected developer ecosystem
A clear diagnosis of the problem is the first step toward building the right solution. For many modern engineering organizations, the core problem isn't a lack of tools, but a lack of connection.
This is especially true for teams that have migrated from a monolith to microservices, where the complexity of a distributed architecture often creates unforeseen challenges. Your engineering world is a sprawling map of services, but there are no street signs, and no one is sure who owns what. All of this creates a significant drag on productivity, innovation, and morale.
The resulting chaos manifests in several costly ways:
An expensive service discovery tax. Every time an engineer needs to use a service they didn't build, they have to become an archaeologist. They dig through outdated wikis, ask questions in crowded Slack channels, and piece together clues to understand what a service does and how to use it. This wasted time, multiplied across your entire engineering team, adds up to thousands of hours of lost productivity every year.
A seemingly endless ownership black hole. When a service has a problem or a dependency needs to be updated, too many teams struggle to identify who owns it. Without clear, reliable ownership information, incident response times balloon, security vulnerabilities linger, and accountability dissolves. This forces engineers to solve problems without context or support, which only creates additional and unnecessary frustration and burnout.
A strategic execution gap. Leadership wants to drive a strategic initiative, like improving production readiness or driving AI adoption. But how can you enforce a standard when you don’t have a reliable inventory of your services? How can you track progress when ownership is unclear? Without a centralized system of record, even the most critical initiatives get stuck in the quicksand of cross-team coordination, unable to gain momentum.
The painful process of writing an RFP is a direct symptom of this underlying disease. You aren't just looking for a tool; you're looking for a way to bring order to the chaos. The rest of this guide will show you how to frame your RFP to find a solution that does exactly that.
Start with why: Tying your IDP to a business goal
The most effective RFP processes begin with a foundational question: What business problem are we trying to solve?
At Cortex, we believe that all successful IDP initiatives are born from the pursuit of Engineering Excellence, which in turn drives business excellence.
Every organization has core business goals, whether it’s unlocking innovation, increasing efficiency, or improving the customer experience. These goals are achieved through four pillars of Engineering Excellence:
Velocity: Shipping faster without sacrificing quality.
Efficiency: Optimizing resources and reducing waste.
Security: Minimizing risk and ensuring compliance.
Reliability: Building resilient, trustworthy products.
The most successful IDP rollouts are those that focus on one primary value pillar to start. This ensures the project has a clear, measurable goal and delivers tangible value from day one. Without this sharp focus, initiatives often become bloated with competing priorities, lose momentum, and ultimately fail to demonstrate the business impact required to justify the investment.
Getting to that point requires engineering teams to build really great RFPs. Based on what we’ve seen, the most effective RFPs are built around the use case that matters most to the business right now. This approach fundamentally shifts your internal developer portal evaluation criteria from a sprawling list of requirements to a focused investigation of a vendor’s ability to solve your most pressing problem. It changes the primary question from 'What features do you have?' to 'How will you help us achieve our specific goal?'
Choosing your initiative: a deep dive into the core value pillars
To help you get started, we’ve developed a framework based on the most common value pillars we see our customers succeed with. The following sections outline key internal developer portal selection criteria based on your primary business goal, helping you define the central theme for your RFP.
Reliability
The business goal: For digital-first businesses, downtime is never an option. This is especially true during make-or-break events like Black Friday, where the resiliency of your products directly defines the success of your business. The goal is to build resilient, trustworthy products and to minimize the impact of incidents when they do occur. This involves both proactive measures to ensure services are production-ready and reactive improvements to speed up incident response.
Key initiatives:
Production Readiness: Define, measure, and automate production readiness standards to reduce the risk of incidents and downtime for critical services.
Incident Response: Improve key incident response metrics (MTTD, MTTR) by ensuring the service catalog is the single source of truth during an incident.
What your RFP must ask:
Does the IDP provide customizable scorecards to define readiness standards (e.g., monitoring configured, runbooks attached, ownership defined)?
Can the platform automate checks against your observability and on-call tools (e.g., Datadog, PagerDuty)?
Does the catalog automatically map service dependencies and surface on-call information in a single place?
When an engineer is paged during an incident, can they query the catalog with natural language questions to find owners or service information directly from their primary tools, like an IDE or chat client?
Can the platform provide meaningful engineering intelligence through tools like a DORA dashboard to correlate reliability initiatives to key metrics? For example, can it show how improving Production Readiness scores impacts Change Failure Rate, or how streamlining incident response with the catalog reduces MTTR?
Security
The business goal: In a world of increasing threats, maintaining a strong security posture is non-negotiable. The goal is to reduce risk by ensuring all services adhere to security best practices and that vulnerabilities are tracked and remediated efficiently.
Key initiatives:
Drive Standardization & Manage Vulnerabilities: Ensure services are compliant with security standards and that vulnerabilities are tied directly to owners for fast remediation.
What your RFP must ask:
Can you build Scorecards to check for security best practices (e.g., security tools enabled, libraries up-to-date, ownership defined)?
Can the IDP ingest data from security scanners (like Snyk or GHAS) and tie vulnerability information directly to service owners?
Can you launch initiatives to drive remediation of critical vulnerabilities and track progress toward security goals?
Does the platform provide high-level reporting for leadership, such as a heatmap of security scores, that allows you to visualize compliance and identify systemic gaps across the organization?
Can the platform correlate security initiatives to developer velocity? For example, can it show that teams focused on maintaining a higher security grade can also maintain or even improve their historic cycle times?
Velocity & Efficiency
The business goal: The ability to ship software quickly and efficiently is a key driver of innovation and competitive advantage. The goal is to accelerate development and reduce cognitive load on developers by creating paved paths for common, repeatable tasks.
Key initiatives:
Pave Golden Paths: Accelerate development by creating self-service workflows for tasks like creating new services or provisioning resources.
What your RFP must ask:
Does the platform provide a way to scaffold new, production-ready services in minutes, based on customizable templates?
Can you create self-service workflows to automate common developer tasks (e.g., provisioning cloud resources, creating a new repo)?
Do these workflows embed your engineering standards (e.g., from your Scorecards) directly into the developer experience?
Can the IDP provide engineering intelligence, like a Velocity Dashboard, to measure the impact of paved paths on developer velocity by tracking key metrics like Cycle Time and PRs Opened?
AI Readiness
The business goal: Artificial intelligence is transforming engineering. The goal is to enable your organization to adopt AI tools and services safely and effectively, ensuring proper governance, tracking adoption, and measuring the maturity and impact of your AI initiatives.
Key initiatives:
Measure AI Adoption & Ensure Governance: Track the use of AI across your engineering organization, measure its impact on developer velocity and quality, and ensure it adheres to internal standards.
What your RFP must ask:
Can the IDP's catalog be extended to track new kinds of entities, like AI models or prompts?
Can you build Scorecards to measure AI maturity, checking for things like defined ownership, proper documentation, and adherence to governance policies?
Does the platform have a Model Context Protocol (MCP) or an equivalent capability that allows you to ask natural language questions about your AI initiatives and service readiness?
Can the platform provide an AI Impact Dashboard to visualize AI adoption and its impact on performance metrics, such as a reduction in PR cycle time or an increase in deployment frequency?
We've created a Project Plan Template to help you and your stakeholders align on the value pillar that will drive your IDP initiative.
Building the RFP: The core capabilities of an impactful IDP
Once you’ve aligned on your "why," you can determine how to evaluate internal developer portals. A modern IDP is an active platform that turns insight into action. Your internal developer platform RFP should allow you to evaluate a vendor’s ability to deliver on this entire loop.
The following section covers what to include in your internal dev portal RFP, breaking down the core capabilities an impactful platform should have:
1. The service catalog: The catalog is the heart of your IDP, but its purpose extends beyond being a simple list. In a dynamic, distributed environment, a manually updated wiki or spreadsheet becomes stale the moment it’s created. A truly impactful IDP provides a dynamic, contextual map of your entire ecosystem that is kept up-to-date automatically. It reflects the reality of your architecture and becomes the single source of truth that developers and leaders can rely on. Without this foundation, any initiative you try to build will be based on unreliable, outdated information.
Key questions for your RFP: How does the platform define and track ownership? How are services and their dependencies discovered and updated automatically? Can it ingest data from any source via API to ensure the catalog is always a comprehensive, real-time reflection of your environment?
2. Scorecards: This is how you drive change. A catalog provides visibility, but Scorecards provide leverage. They are the engine that allows you to translate your engineering standards and business goals into measurable, automated checks that drive improvement over time. For example, a "Production Readiness" Scorecard for your chosen reliability initiative isn't just a checklist; it's an active system that constantly checks if services have runbooks, if monitoring is configured, and if on-call schedules are set. It shows teams exactly where they stand and what they need to do to improve, turning a high-level goal into actionable, day-to-day work.
Key questions for your RFP: How does the platform allow you to build custom Scorecards for your specific initiatives (e.g., Production Readiness, AI Maturity)? How extensible are the rules, and can they be applied to different types of entities, not just services? Can you launch organization-wide initiatives based on Scorecard results to track progress?
3. Self-service & workflows: An impactful IDP makes it easy for developers to do the right thing by paving golden paths. Instead of navigating a complex series of tickets and manual steps to get something done, developers can use self-service capabilities to accelerate their work. Scaffolding a new, production-ready microservice that already meets all of your production readiness standards can go from a week-long process to a five-minute task. The ultimate goal is to embed your standards directly into the development process, which improves both velocity and standardization at the same time.
Key questions for your RFP: How does the platform enable developer self-service? Can you create custom workflows for common tasks like provisioning resources or creating new microservices? Can these workflows be integrated with your Scorecards to ensure that anything new is built to your standards from day one?
4. Engineering intelligence: The first half of the feedback loop is understanding what’s happening across your engineering organization. True engineering intelligence unifies data from your entire toolchain—your Git provider, CI/CD, project management, and incident response tools—into a single, coherent view. This allows leaders to move beyond gut feel and track the core metrics that define engineering health, like DORA and cycle time. It provides the high-level visibility needed to spot trends, identify systemic bottlenecks in the development lifecycle, and make data-driven decisions about where to invest.
Key questions for your RFP: Does the platform provide Engineering Intelligence capabilities, such as DORA and Velocity dashboards, to track performance metrics and identify bottlenecks? Can it unify data from a wide range of third-party tools to give a complete picture of engineering health?
5. The Model Context Protocol (MCP): The second half of the loop is making data accessible and actionable for everyone. A Model Context Protocol (MCP) provides a conversational interface that sits on top of your entire system of record, allowing any engineer to ask natural language questions and get immediate, contextual answers. Instead of digging through multiple tools during an incident, an engineer can simply ask, "Give me the runbooks, dependencies, and recent deploys for this service." This capability puts critical information at engineers’ fingertips right where they work, dramatically reducing context switching and accelerating problem resolution.
Key questions for your RFP: Does the platform offer a Model Context Protocol (MCP) or an equivalent natural language interface to conversationally query the catalog? Can it provide on-demand information about service ownership, dependencies, and Scorecard status?
A new standard for engineering excellence
A successful RFP for an IDP functions as a strategic platform that connects your engineering efforts directly to business value, rather than a simple feature checklist. By building your internal dev portal RFP around a core business initiative and evaluating vendors on their ability to deliver on the complete insight-to-action loop, the process is no longer about just buying a tool, but about investing in a new foundation for engineering excellence.
Ready to see how Cortex can help you achieve your Engineering Excellence goals? Schedule a demo today.
