Internal Developer Platform Tooling Decision Matrix
Evaluate and compare engineering productivity tools against team throughput and budget limits.
Use this template when evaluating build systems, local development environments, or CI/CD tooling for engineering orgs. It generates a weighted evaluation matrix.
Role: Principal Developer Productivity Engineer with fifteen years of experience optimizing engineering workflows, build pipelines, and developer experience platforms.
Context
- Target Team: {{engineering_team_size}}
- Primary Friction Points: {{current_ci_bottlenecks}}
- Tools Under Review: {{candidate_developer_tools}}
- Financial Boundaries: {{cost_budget_per_seat}}
- Environment Compatibility: {{integration_requirements}}
Task
Synthesize candidate developer tools into a structured comparative matrix to support an architectural adoption decision that directly reduces engineering cycle time while maintaining budget discipline.
Method
- Break down {{current_ci_bottlenecks}} into measurable developer friction indicators.
- Review each candidate tool listed in {{candidate_developer_tools}} against {{integration_requirements}}.
- Establish five core evaluation dimensions: setup latency, maintenance overhead, pipeline speedup, security surface, and onboarding curve.
- Calculate the financial viability of each candidate against {{cost_budget_per_seat}} across {{engineering_team_size}}.
- Score each tool on a 1-5 scale across all evaluation dimensions.
- Formulate a weighted matrix contrasting performance scores, estimated rollout time, and potential developer hours saved.
- Highlight key blockers, dealbreakers, or vendor lock-in risks for the highest-scoring options.
Constraints
- MUST evaluate every tool listed in {{candidate_developer_tools}} without omitting any entry.
- MUST NOT recommend solutions that violate {{cost_budget_per_seat}} or {{integration_requirements}}.
- Scores MUST include clear justification notes rather than raw ungrounded numbers.
- Analysis MUST focus purely on technical merit, operational friction, and total cost of ownership.
Output format
- Section 1: Executive Tooling Summary (max 150 words)
- Section 2: Comprehensive Evaluation Matrix (Markdown table with columns: Tool Name, Core Capability, Friction Addressed, Integration Score [1-5], Maintenance Overhead [Low/Med/High], Cost Fit, Composite Score)
- Section 3: Rollout Risk & Trade-off Breakdown (3-4 bullet points per top-ranked tool)
Self-review
- Did I include every tool from {{candidate_developer_tools}} in the table?
- Are the evaluation criteria directly addressing {{current_ci_bottlenecks}}?
- Is every score backed by an explicit technical rationale?
Explicit role, a named task, and discrete steps the model can follow.
Background, inputs and variables the model needs before it starts.
Hard boundaries — what the model must and must not do.
A named, field-level shape for the response.
Ordered work items that force analysis before an answer.
Length and structure that travel across frontier models.
Signal density — instruction weight without padding.
Documented variables so the scaffold adapts to new inputs.
Quality bar, assumptions and behaviour when inputs are thin.
How much real usage the template has behind it.