80% of Companies Adopting IDPs by 2026—But Our 8-Month Backstage Implementation Has Zero Metrics to Show Executives. How Do You Justify Investment Before Value?

General
1

I’m 5 months into a Backstage implementation at my company, and I’m hitting a wall I didn’t expect. Not a technical wall—the platform is coming together nicely. The wall is with leadership.

Our CFO just asked me to present ROI metrics for our Internal Developer Platform at next quarter’s review. The problem? We won’t have meaningful productivity metrics for another 3-4 months minimum. Maybe longer.

The Reality of Platform Building

Here’s where we are:

  • Month 1-2: Planning, architecture decisions, initial setup
  • Month 3-4: Basic service catalog, authentication, core plugins
  • Month 5 (now): Custom plugin development, team onboarding beginning
  • Month 6-8 (projected): Gradual rollout to development teams
  • Month 9-12: Actually measuring impact on velocity, deployment frequency

The research backs this up. According to platform engineering data from 2026, 40.9% of platform teams can’t demonstrate measurable value within 12 months. Yet when ROI finally materializes, it’s significant—Forrester found 224% ROI and 20% productivity gains for companies that completed their IDP implementations.

We’re in what I’m calling the “valley of death”—we’ve invested significant engineering time and budget, but can’t yet prove the value with data.

The Pressure from Leadership

I understand the CFO’s perspective. We’ve allocated:

  • 3 full-time platform engineers for 6-9 months
  • ~K in infrastructure and tooling
  • Opportunity cost of not having those engineers on product features

From a financial standpoint, that’s ~K invested with zero measurable return yet. In a company that scrutinizes every quarterly budget line, this looks risky.

But here’s what I keep thinking: Platforms aren’t projects you can measure monthly. They’re infrastructure investments that compound over years.

What I’ve Tried (That Hasn’t Worked)

Qualitative feedback: “Developers are excited about self-service infrastructure!” → CFO wants numbers, not enthusiasm

Future projections: “Once deployed, we expect 25% faster deployment times” → CFO says “Come back with actual data, not forecasts”

Industry benchmarks: “80% of companies are adopting IDPs by 2026” → CFO responds “Just because everyone’s doing it doesn’t mean it’s right for us”

All fair pushback, honestly. But I’m stuck.

My Questions for This Community

For those who’ve completed IDP implementations:

  1. How did you maintain executive support during the 6-12 month build phase before metrics existed?
  2. What leading indicators did you track to show progress when lagging indicators (deployment speed, productivity) weren’t ready?
  3. Did anyone face cancellation pressure mid-implementation? How did you navigate it?

For those still building:
4. What interim metrics are you showing leadership?
5. How do you balance “move fast to show value” with “build it right for long-term success”?

The irony isn’t lost on me: we’re building a platform to accelerate engineering velocity, but the platform itself requires patience that quarterly business reviews don’t naturally accommodate.

I’m committed to this implementation because I’ve seen the long-term value at previous companies. But I need to bridge the gap between “this will pay off in 12-18 months” and “justify your budget this quarter.”

How have you solved this?

Context: 40-person engineering team at a fintech company, 5 months into Backstage.io implementation, leadership pressing for ROI metrics.

2

Luis, I’ve been in your exact position. Two years ago at my previous company, we were 7 months into a platform implementation when our board started questioning the investment. Here’s how we navigated it.

Reframe as Strategic Investment, Not Tactical Project

The biggest mistake I see leaders make is presenting platform engineering as a “project” with a defined end date and measurable deliverables. That framing sets you up to fail because platforms are never “done”—they evolve.

Instead, I repositioned our platform as a strategic infrastructure investment, similar to migrating to cloud or modernizing security architecture. Nobody expects cloud migration ROI in quarter 1. Why should platform be different?

When I met with our CFO, I explicitly said: “This is a multi-year capability we’re building, not a 6-month project. The question isn’t ‘what’s the ROI this quarter,’ it’s ‘can we scale engineering without this infrastructure?’” That shifted the conversation.

Leading Indicators We Tracked Before Metrics Existed

Here’s what worked for us during the build phase:

1. Developer onboarding time (even partial)

  • Before platform: 3-4 weeks for new engineer to deploy first service
  • At month 6 of platform build: 2 weeks (even though platform incomplete)
  • This showed directional progress even before full rollout

2. Service creation speed for early adopters

  • Tracked the 2-3 pilot teams using platform
  • Measured: time from “we need a new service” to “service is live in production”
  • Showed 40% reduction even with incomplete platform

3. Reduction in infrastructure support tickets

  • Platform enabled self-service for common tasks (create database, set up CI/CD)
  • Support ticket volume dropped 25% in pilot teams
  • Demonstrated operational efficiency gains before productivity metrics

4. Platform team velocity metrics

  • Tracked our own story points, features shipped, plugin completions
  • Showed we were making progress on the roadmap, not stalled

The Phased Rollout Strategy That Saved Us

Here’s the key insight: You don’t need to wait until month 12 to show value. You need early wins from partial deployment.

We did this:

  • Month 6: Selected 2 friendly teams as beta users (service catalog + docs only)
  • Month 8: Expanded to 5 teams with additional features (CI/CD integration)
  • Month 10: Opened to 50% of engineering (self-service infra)
  • Month 12: Full rollout with complete feature set

By month 8, we had enough data from 5 teams to demonstrate 20-30% productivity improvements in specific workflows. That’s not full ROI, but it’s proof of concept that satisfied leadership.

The CFO’s actual question isn’t “is this worth it?”—it’s “are we confident this will work?” Early adopter data answers that question even if full metrics don’t exist yet.

One More Thing: Executive Sponsor Matters

I made sure our CTO was personally invested in the platform initiative. When the CFO pushed back, the CTO defended it: “This is foundational for our 3-year engineering strategy. Cutting it now means we’ll struggle to scale next year.”

Having an executive champion who understands delayed ROI is critical. If you don’t have that, build it. Get your CTO or VP Eng to own this with you.

Your Specific Situation

At 5 months in with basic catalog working, you should be able to:

  1. Get 2-3 teams onto the platform NOW (even if incomplete)
  2. Measure their experience: onboarding speed, service creation time, satisfaction
  3. Present those pilot results at your CFO meeting

Say: “We have preliminary data from 3 pilot teams showing 30% faster service creation. We expect this to scale across all 40 engineers by month 9, with full metrics by month 12.”

That bridges the gap between “no data” and “full ROI.”

You’ve got this. The valley of death is real, but you’re close to emerging from it.

3

This is such a product thinking problem disguised as an engineering problem.

Luis, I see teams make this mistake constantly: they treat internal platforms like infrastructure projects when they should treat them like products seeking product-market fit.

The Product-Market Fit Framework for Internal Platforms

When I evaluate external products for PMF, I look for:

  1. Early adopter enthusiasm (not forced adoption)
  2. Organic usage growth (people want to use it)
  3. Qualitative feedback that’s specific and actionable
  4. Retention (users keep coming back)

Your CFO isn’t wrong to want proof. But the proof doesn’t have to be DORA metrics yet. It can be signals that developers actually want this platform.

The Early Adopter Strategy

Here’s what I’d recommend at month 5:

Find 2-3 “design partner” teams right now. Not teams you mandate to use the platform—teams that volunteer because they have pain points the platform solves.

For us in product, we call these design partners. They get early access in exchange for feedback. For platforms, these are your beta teams.

Measure their experience qualitatively first:

  • “How much time did self-service save you this week?”
  • “What would you have had to do without the platform?”
  • “Would you recommend this to other teams?”

Collect 5-6 quotes from actual developers. Present those to your CFO as evidence of demand before you have productivity metrics.

CFOs understand market validation. If developers are saying “this saved me 2 hours setting up CI/CD,” that’s real value even without aggregate metrics.

Use Net Promoter Score as Interim Measure

This is controversial, but hear me out: NPS for internal developer platforms works.

Every month, ask your pilot users: “On a scale of 0-10, how likely are you to recommend this platform to other teams?”

  • NPS above 30: You have PMF. Keep building.
  • NPS 0-30: You have work to do on UX/features.
  • NPS below 0: Stop and reassess what you’re building.

I’d present this to your CFO: “Our pilot teams have an NPS of 45, indicating strong product-market fit. We’re confident this will scale.”

That’s not ROI, but it’s confidence in future ROI, which is what leadership actually needs at month 5.

The Metrics That Matter at Your Stage

Month 5-8 isn’t about proving ROI. It’s about proving trajectory toward ROI. Show:

  1. Adoption curve: X teams using platform today, Y teams next month
  2. Feature requests: Developers asking for features means they’re engaged
  3. Usage frequency: Are pilot teams using it daily or ignoring it?
  4. Qualitative wins: “Team A deployed 3 services in 2 days instead of 2 weeks”

These are product health metrics. They predict future ROI even if they don’t quantify it yet.

Reframe the CFO Conversation

Instead of saying “we need 12 months to show ROI,” say:

“We’re at month 5 of a 12-month rollout. Our pilot data shows strong developer adoption and 30-40% time savings for early users. We’ll have organization-wide metrics by month 10, but current trajectory indicates we’re on track for the 20% productivity gains industry benchmarks predict.”

You’re not promising ROI today. You’re showing leading indicators that predict ROI, which is exactly how we validate product investments.

One More Thing: Beware Sunk Cost Fallacy

Your CFO is right to push. If the platform isn’t showing signals of adoption and value by month 8-9, you might actually need to pivot or cut losses.

I’ve seen teams spend 18 months building platforms nobody wants because they never validated product-market fit. Don’t fall into that trap.

Pilot early. Validate often. Iterate based on feedback. That’s how you know you’re building something valuable before you’ve spent $1M.

Good luck. Let us know how the CFO conversation goes.

4

Luis, this resonates deeply. I’ve navigated this exact challenge twice—once successfully, once… less so. Let me share what I learned.

This Is a Change Management Problem

What you’re facing isn’t primarily a metrics problem or even a technical problem. It’s organizational change management under financial scrutiny.

Platform engineering requires teams to change how they work. Change creates resistance. And resistance needs executive air cover to overcome.

Without that executive support, your platform team will face:

  • Teams saying “we don’t have time to migrate”
  • Pushback on “yet another tool to learn”
  • Passive adoption where teams use it minimally but don’t embrace it

All of which makes your ROI metrics even worse, creating a doom loop.

The Monthly Platform Wins Newsletter

Here’s a tactic that worked for us: Make platform progress visible through storytelling, not just metrics.

Every month, I sent an email to exec team + engineering managers called “Platform Wins.” Format:

This Month:

  • Team X deployed 3 services using self-service—previously took 2 weeks, now takes 2 days
  • New engineer Y onboarded and deployed to production in 5 days (previous average: 21 days)
  • Platform team shipped: [specific features]
  • Developer quote: “This saved me hours of config hell”

Next Month:

  • Rolling out to 2 more teams
  • Building [specific feature] that will enable [business capability]

This did two things:

  1. Humanized the work: Execs saw real developers benefiting, not abstract productivity gains
  2. Demonstrated momentum: Even without final ROI, progress was undeniable

CFOs respond to narrative + data. You need both.

Executive Sponsor is Non-Negotiable

I can’t stress this enough: You need a VP or C-level champion who will defend this investment when you’re not in the room.

At my first company, I had the CTO’s backing. When the CFO questioned the platform mid-implementation, the CTO said: “This is foundational infrastructure. Cutting it now is like stopping a bridge construction halfway—we get nothing and waste everything we’ve invested.”

That defense bought us 6 more months to prove value. We delivered.

At my second company, I didn’t have that sponsor. The platform project got cut at month 8 despite strong pilot results. We lost talented engineers who felt demoralized. It set our scaling efforts back 18 months.

If you don’t have an executive sponsor, building one is your #1 priority. More important than any feature or metric.

The Risk of Mid-Implementation Cancellation

Let me be blunt about something nobody talks about: Canceling a platform mid-implementation is often worse than never starting.

Here’s why:

  1. Sunk cost with zero recovery: You’ve invested $500K with nothing to show
  2. Team morale crater: Engineers who believed in the vision feel betrayed
  3. Technical debt accumulates: You’ve partially migrated some services, creating operational complexity
  4. Future platform attempts poisoned: Leadership remembers “we tried this and it failed”

I’ve seen companies struggle for years after killing platforms mid-build because nobody wants to propose similar initiatives again.

Present this risk to your CFO: “The question isn’t just ‘what if this succeeds?’ It’s ‘what’s the cost if we stop now?’”

Stopping at month 5 might feel like limiting losses. But it often locks in the losses while eliminating any chance of recovery.

What Actually Works for Your Situation

Based on your timeline (month 5 of 12), here’s my playbook:

Week 1-2: Secure executive sponsor

  • If you don’t have CTO/VP Eng backing, build it now
  • Frame platform as strategic enabler for 2027 scaling plans
  • Get them to own this initiative publicly

Week 3-4: Launch pilot with 2-3 friendly teams

  • Pick teams with real pain points platform solves
  • Measure their experience obsessively
  • Collect quotes and time-saved estimates

Week 5-8: Monthly “Platform Wins” communication

  • Send to exec team and eng managers
  • Highlight pilot team successes
  • Show feature velocity and roadmap progress

Month 7: Present interim results

  • “Pilot teams show 30-40% productivity improvements”
  • “On track for full deployment month 9-10”
  • “Full ROI metrics available month 12”

This buys you time while demonstrating progress.

One More Thing: Platform vs Product Team Time

I see you have 3 FTE platform engineers. That’s appropriate for 40 developers.

But here’s a question: What percentage of their time is spent building new platform capabilities vs maintaining/supporting what exists?

If it’s drifting toward 70% maintenance / 30% new features, you have a problem. That suggests either:

  • Platform complexity is too high
  • You’re building things that don’t work well enough
  • Team is undersized for scope

Track this ratio and surface it if needed. It’s a leading indicator of sustainability problems.

You’ve got this. The valley of death is navigable, but you need political capital + early wins + executive air cover. Build those three things in parallel with the technical platform.

5

Oh man, Luis, this hits home. Let me share something from a different angle—what I learned from my startup’s failure.

The Vanity Metrics Trap

When my startup was struggling to show traction, we optimized for metrics that looked good but didn’t actually matter. DAUs went up. Engagement time increased. Our dashboard looked amazing.

Then we ran out of money because none of those metrics translated to revenue or retention.

I see a similar risk with platform engineering. It’s really easy to track:

  • Number of services deployed :white_check_mark:
  • Lines of code in platform :white_check_mark:
  • Plugin count :white_check_mark:
  • API calls to platform services :white_check_mark:

But do any of those actually prove the platform is valuable?

What Actually Matters vs What’s Easy to Measure

Your CFO is asking the right uncomfortable question: “Does this make us money or save us money?”

Everything else is theater.

Here’s what I’d focus on showing:

Cost avoidance (this is real money)

  • “Without platform, we’d need to hire 2 more DevOps engineers at $350K total”
  • “Self-service infrastructure reduces ops support tickets by 40%, freeing up X engineer-hours”
  • “Faster deployments = features ship 20% faster = revenue impact”

That last one is hard to quantify, but it’s the real business case.

The Honest Conversation About What’s Realistic

Michelle and Keisha gave you great tactical advice. But I want to add a dose of startup realism:

If your CFO genuinely doesn’t believe in this investment, no amount of interim metrics will save it.

I tried every tactic to convince our investors the pivot would work. Data, testimonials, projections. They nodded along but had already mentally written us off.

So my question back to you: Does your CFO actually want this to succeed, or are they looking for justification to kill it?

Because if it’s the latter, you need to have a different conversation. Not about metrics—about strategic commitment.

Transparent Communication > False Optimism

One mistake I made at my startup: I kept saying “we’re almost there” when we weren’t. It eroded trust.

Don’t do that with your platform.

If month 5 is rough and you’re behind schedule, say that: “We’re at 60% of planned progress. Here’s why, here’s our revised timeline, here’s the risk if we stop now.”

CFOs hate surprises more than they hate delays.

Showing you understand the risks and have a realistic plan builds more confidence than painting rosy pictures that don’t materialize.

The Question That Matters Most

Here’s the core question for your CFO meeting:

“Do we believe that scaling from 40 to 100 engineers without platform infrastructure is viable?”

If the answer is yes, then maybe platform is premature.

But if the answer is no—if everyone agrees you’ll hit scaling problems without better infrastructure—then the question isn’t “should we build a platform?” It’s “how do we bridge the gap until platform value materializes?”

That reframe might help.

One More Thing: Know When to Pivot

I stayed with my startup 6 months too long after it was clear we wouldn’t succeed. Ego, sunk cost fallacy, denial—all of it.

If you hit month 8-9 and nobody wants to use the platform, or pilot teams report it’s making things worse, don’t double down. Pivot or cut losses.

But right now, at month 5, you’re not there yet. You’re in the hard middle where it’s supposed to feel impossible.

Push through. But eyes wide open about what success actually requires.

Rooting for you. Let us know how the CFO conversation goes—we all learn from these war stories.