Framework Comparisons
Side-by-side analysis of engineering frameworks, metrics, and methodologies. Data-driven. No opinions without evidence.
PDI vs. DORA Metrics
Financial Health vs. Delivery Speed
DORA measures delivery speed. PDI measures technology capital health. Both are essential — here's when to use each and how they complement each other.
| Dimension | PDI | DORA |
|---|---|---|
| Measures | Technology capital health in dollars | Delivery throughput and stability |
| Audience | Board, CFO, PE firms | Engineering managers, CTOs |
| Language | Financial ($, ROI, risk) | Technical (frequency, time) |
| Focus | Asset health and debt accumulation | Delivery speed and reliability |
| Frequency | Quarterly or at investment events | Continuous monitoring |
| Blind Spot | Doesn't measure delivery velocity | Doesn't quantify economic impact |
Use both. PDI tells you WHERE to invest. DORA tells you IF your investment is improving delivery. Together they give a complete picture.
Build vs. Buy
The $500K Decision Framework
Building in-house gives control but costs 3-5x the initial estimate. Buying is faster but creates vendor lock-in. Here's the TCO framework.
| Dimension | Build | Buy |
|---|---|---|
| Time to Value | 3-12 months | 1-4 weeks |
| Year 1 Cost | $200K-$1M+ (development) | $12K-$100K (license) |
| Year 3 TCO | $500K-$3M (build + maintain) | $50K-$500K (license + integration) |
| Customization | Unlimited | Limited to vendor roadmap |
| Risk | Scope creep, team dependency | Vendor lock-in, sunset risk |
| Core Competency | When the capability IS your product | When it's infrastructure |
Build your differentiation. Buy your infrastructure. The line between them is where most CTOs make expensive mistakes.
Revenue Per Engineer Benchmarks
Elite ($1M+) vs. Average ($200-500K)
Revenue per engineer varies 10x between elite and average companies. Here's what drives the gap and how to close it.
| Dimension | Elite ($1M+) | Average |
|---|---|---|
| RPE | Stripe $3.2M, Figma $2.8M | $200-500K (most growth SaaS) |
| Team Size | Lean, senior-heavy | Growing, mixed levels |
| Innovation Tax | <20% | 40-60% |
| Feature Usage | >50% features used monthly | 20-30% features used |
| Automation | Everything automated | Manual processes persist |
| Platform | Strong internal platform | Teams duplicate work |
RPE is not about cutting engineers — it's about maximizing the value each engineer creates. The gap is organizational friction, not individual skill.
Technical Debt Classification
Prudent vs. Reckless — Not All Debt Is Equal
Some technical debt is strategic. Some is negligent. The difference determines whether debt helps or kills your organization.
| Dimension | Prudent | Reckless |
|---|---|---|
| Intent | Deliberate trade-off | Accidental or ignorant |
| Documentation | Logged with plan | Unknown until it breaks |
| ROI | Positive (speed to market) | Negative (pure liability) |
| Priority | Scheduled remediation | Emergency triage |
| Board Impact | Explainable investment | Hidden liability |
| Example | Hardcoded config for launch | Copy-paste code everywhere |
Prudent debt is a tool. Reckless debt is a cancer. The difference is documentation, intent, and a remediation timeline.
Scrum vs. Kanban
Sprint-Based vs. Flow-Based Delivery
Scrum works great for teams that need structure. Kanban works for teams that need flow. Neither is universally better.
| Dimension | Scrum | Kanban |
|---|---|---|
| Cadence | Fixed sprints (1-4 weeks) | Continuous flow |
| Planning | Sprint planning ceremony | Just-in-time execution |
| WIP Limits | Sprint capacity | Explicit per-column limits |
| Best For | Feature development, new teams | Operations, experienced teams |
| Metrics | Velocity, sprint burndown | Cycle time, throughput |
| Overhead | High (ceremonies, roles) | Low (board-driven) |
Scrum for feature teams that need predictability. Kanban for operations teams that need flow. ScrumBan for teams that outgrow Scrum.
Monolith vs. Microservices
The Architecture Decision That Costs $2M to Reverse
Every startup should start with a monolith. Most know when to split. Few know the true cost of premature decomposition.
| Dimension | Monolith | Microservices |
|---|---|---|
| Team Size | Up to 20 engineers | 20+ with domain ownership |
| Deployment | Single deploy (simple) | Independent deploys (complex) |
| Latency | In-process calls (fast) | Network calls (overhead) |
| Debugging | Single codebase (easy) | Distributed tracing (hard) |
| Cost | Lower infrastructure | 2-5x infrastructure cost |
| Scaling | Vertical (limited) | Horizontal (unlimited) |
Start monolith, extract when Conway's Law demands it. The worst outcome is premature microservices — high cost, high complexity, low benefit.
Fine-Tuning vs. RAG
Which AI Strategy Actually Makes Economic Sense?
Fine-tuning gives model-level customization but costs $10K-$500K per training run. RAG gives context-level customization at a fraction of the cost.
| Dimension | Fine-Tuning | RAG |
|---|---|---|
| Setup Cost | $10K-$500K per run | $1K-$10K (once) |
| Latency | Same as base model | +200-500ms (retrieval) |
| Data Freshness | Frozen at training time | Real-time updates |
| Accuracy | High for style/behavior | High for factual recall |
| Maintenance | Re-train for updates | Update knowledge base |
| Use Case | Tone, format, reasoning | Knowledge retrieval |
Use RAG for knowledge. Use fine-tuning for behavior. Use both when your use case demands it. For most products, start with RAG — it's cheaper, faster, and updateable.
Staff Augmentation vs. Managed Delivery
Outsourcing Models — Which Burns Less Cash?
Staff augmentation gives you bodies. Managed delivery gives you outcomes. The wrong choice costs 40% more and delivers 50% less.
| Dimension | Staff Aug | Managed |
|---|---|---|
| Control | You manage the team | Vendor manages delivery |
| Cost | $150-250/hr per person | Fixed bid or milestone |
| Risk | On your P&L | Shared with vendor |
| Hiring Speed | 2-4 weeks | 4-8 weeks (team ramp) |
| Knowledge | Stays with your team | Risk of vendor lock-in |
| Best For | Known work, capacity gap | Unknown scope, outcome needed |
Staff aug for capacity gaps with known work. Managed delivery for outcomes you can't staff internally. Never use staff aug for innovation — you're paying for hours, not ideas.
Platform Engineering vs. SRE
Two Approaches to Developer Productivity
Platform engineering builds internal developer tools. SRE keeps systems running. Both reduce friction, but from different angles.
| Dimension | Platform Eng | SRE |
|---|---|---|
| Focus | Developer experience | System reliability |
| Output | Internal tools, abstractions | SLOs, incident response |
| Metrics | Developer satisfaction, MTTR | SLO compliance, MTTR |
| Team Size | 2-5% of engineering org | 5-10% of engineering org |
| ROI Horizon | 6-12 months | 3-6 months |
| Risk of Not Having | Tooling sprawl, slow onboarding | Outages, alert fatigue |
Start with SRE (you need reliability first). Add platform engineering when tool sprawl becomes the bottleneck. Best orgs have both.
CapEx vs. OpEx in R&D
How Engineering Costs Hit the Financial Statements
Whether engineering work gets capitalized (CapEx) or expensed (OpEx) changes your EBITDA, tax implications, and how investors value your company.
| Dimension | CapEx | OpEx |
|---|---|---|
| Accounting | Capitalized as an asset | Expensed immediately |
| Impact | Improves EBITDA | Reduces EBITDA |
| Example | New feature development | Bug fixes, maintenance |
| Valuation | Increases asset base | Reduces reported profitability |
| PE Impact | Scrutinized in due diligence | Expected line item |
| Ratio Target | 60-70% of R&D | 30-40% of R&D |
The CapEx/OpEx ratio reveals engineering health. If less than 50% of R&D is capitalizable, you're spending most of your budget keeping the lights on — not innovating.
Need a Custom Framework Analysis?
Book a strategy session for a comparison tailored to your stack, team, and business model.