We Spent 18 Months on DIY Backstage. Here's Why We're Moving to Managed

vp_eng_keisha · February 19, 2026, 9:00pm

I’m writing this because I wish someone had been this honest with me 18 months ago when we started down the DIY Backstage path.

The headline: What we thought would be “free” ended up costing us over ,000 in engineering time, delayed our platform roadmap by a year, and still resulted in only ~12% daily active usage among our developers.

We’re moving to a managed solution. Here’s the full story.

Context: EdTech Startup, Rapid Growth

When we started evaluating IDPs in late 2024, we were a 25-person engineering team scaling fast. We knew we needed better service ownership, clearer dependencies, and faster onboarding as we planned to double the team.

Backstage was the obvious choice - 89% market share, CNCF project, rich plugin ecosystem. The question was: self-host or managed?

We chose self-host. That decision, in hindsight, was wrong for us.

The “Free” Math

Here’s how we justified DIY Backstage:

Managed solutions cost: -100/engineer/month
Our projected team size: 80 engineers
Annual cost at scale: ,000 - ,000/year

DIY Backstage cost: “Free” (just implementation time)

Seemed like an easy decision. Invest a few months upfront, save -100k annually forever.

The Real Math

Here’s what actually happened:

Phase 1 - Planning (6 months):

1 senior platform engineer (50% time)
Architecture design, plugin evaluation, infrastructure planning
Cost: ~,000

Phase 2 - Implementation (12 months):

2 platform engineers (100% time)
Core setup, plugin integration, custom development, migration
Cost: ~,000

Ongoing - Maintenance (current):

1.5 platform engineers (ongoing)
Plugin updates, bug fixes, version upgrades, support
Annual cost: ~,000

Total 18-month cost: ,000+

And we’re STILL not feature-complete compared to Spotify Portal or Roadie.

The Hidden Costs Nobody Warned Us About

Beyond the direct engineering costs, here’s what blindsided us:

Plugin Maintenance Hell

We started with 12 plugins. Each one needs:

Version compatibility testing before Backstage upgrades
Monitoring for security vulnerabilities
Bug fixes when things break
Custom modifications to fit our needs
Documentation for our team

Three plugins were abandoned by their maintainers. We had to fork and maintain them ourselves.

Two plugins had conflicting dependencies. Solved with workarounds that broke on every upgrade.

Plugin debt is real and expensive.

The Version Upgrade Treadmill

Backstage releases frequently. That’s great for the ecosystem. Terrible for maintenance.

Every upgrade requires:

Testing all plugins for compatibility
Reviewing breaking changes
Updating custom code
Regression testing
Coordinating deployment window

We’re currently 4 versions behind because we don’t have capacity to upgrade. Which means we can’t use newer plugins. Which means we’re missing features that managed solutions have.

We’re paying to stay behind.

Custom Integration Burden

Every internal tool needs integration:

GitHub (relatively easy)
Jenkins (plugin exists but needed customization)
Our internal deployment system (built from scratch)
Our service mesh (built from scratch)
Cost tracking system (built from scratch)
Security scanning (built from scratch)

Each custom integration is code we own and maintain forever. Each one adds to our technical debt.

The Adoption Challenge

Even after all this investment, our actual usage is disappointing.

Who uses it:

New engineers (first 2 weeks of onboarding)
Tech leads (service catalog during architecture review)
On-call engineers (finding ownership during incidents)

Who doesn’t:

Most engineers in daily work
Anyone who can solve their problem with grep + Slack
Developers who found workarounds

Daily active users: ~10 out of 82 engineers (12%)

This isn’t because the implementation is bad. It’s because we built infrastructure before we built the culture and processes that make it valuable.

The Opportunity Cost

Here’s what really kills me: What could we have built instead?

With k and 18 months of platform engineering time, we could have:

Built golden path templates for all our service types
Created self-service infrastructure provisioning
Developed comprehensive local development tooling
Implemented automated testing and deployment pipelines
Built internal tools that developers actually asked for

Instead, we built a portal that most developers don’t use.

Why We’re Moving to Managed

We’ve decided to move to Spotify Portal (or possibly Roadie - still evaluating). Here’s the math that changed our minds:

Managed solution cost: /engineer/month × 80 engineers = ,000/year

Current DIY cost: ,000/year (and growing as team scales)

Savings: ,000/year

Plus:

No more version upgrade burden
Professional support when things break
Features we don’t have to build
Security patches we don’t have to apply
Onboarding guides we don’t have to write
Platform engineers freed up for high-value work

The managed solution is literally cheaper AND better than DIY.

What We Learned

1. “Free” Is a Lie

Open source isn’t free. It’s a different cost model. Instead of paying vendor, you pay:

Implementation costs
Maintenance costs
Opportunity costs
Operational costs

For some orgs, that math works out cheaper. For us, it didn’t.

2. Commodity Infrastructure Isn’t Competitive Advantage

Running our own Backstage instance doesn’t differentiate our EdTech platform. Our teaching tools differentiate us.

Platform engineering should enable differentiation, not consume resources.

Great platform teams focus on:

Golden paths specific to their domain
Integrations with their specific toolchain
Custom workflows for their developers
Unique organizational needs

They don’t focus on:

Keeping web frameworks up to date
Managing plugin dependencies
Running infrastructure for their infrastructure

3. Build vs Buy Requires Honest Assessment

The build vs buy decision should consider:

Build makes sense when:

You have unique requirements
You have strong platform team capability
Maintenance cost is acceptable
Build time is acceptable
You can match vendor feature velocity

Buy makes sense when:

Solution is commodity
Vendor has economics of scale
Your team is small or stretched
Time to value matters
You want to focus engineering on differentiation

We convinced ourselves we met the “build” criteria. We didn’t.

4. Platform Team Size Matters

If you have a 10+ person platform team, DIY Backstage might be manageable. If you have 2-3 people trying to support 80+ engineers, managed solutions make way more sense.

We were trying to do everything: CI/CD, cloud infrastructure, developer tooling, AND maintain Backstage. Something had to give.

5. Organizational Maturity Gates Technology Choices

Michelle’s recent post about platform engineering maturity really resonated. We jumped to a Stage 4 solution at Stage 2 maturity.

We didn’t have:

Clear service ownership model
Established golden paths
Strong platform team credibility
Developer trust and adoption

Technology can’t fix organizational immaturity. We learned this the expensive way.

What I’d Do Differently

If I could restart 18 months ago:

Start with managed solution: Get portal up fast, learn what’s valuable
Focus on golden paths: Invest in making developers productive
Build organizational maturity: Service ownership, standards, processes
Measure ruthlessly: Track developer productivity, not portal features
Reassess build vs buy yearly: Maybe DIY makes sense at 200 engineers

The Uncomfortable Truth

The real reason we chose DIY wasn’t the cost math. It was ego.

We’re a tech company. We’re engineers. We wanted to prove we could build it ourselves. Open source means we should self-host, right?

That’s not strategy. That’s pride.

The hardest part of this decision wasn’t the technical analysis. It was admitting we made the wrong call.

Questions for This Community

For those who’ve been through similar evaluations:

How did you calculate TCO honestly? What costs did we miss?
At what team size does DIY Backstage become cost-effective?
For those using managed solutions - what’s your experience been?
For those successfully running DIY - what’s your team size and structure?
How do you measure IDP ROI beyond “portal exists”?

I know there are orgs where DIY Backstage is the right call. I want to understand what makes it work for them, so I can better understand where we went wrong.

Moving Forward

We’re not abandoning platform engineering. We’re doubling down on it.

But we’re doing it smarter:

Managed portal so platform engineers focus on golden paths
Clear metrics tied to developer productivity
Quarterly assessment of build vs buy for each component
Honesty about what differentiates us vs what’s commodity

Platform engineering is journey, not a destination. And sometimes the journey means admitting when you took a wrong turn.

I’m sharing this because I suspect we’re not alone. The 89% market share means lots of orgs are implementing Backstage. The 10% adoption rate suggests many are struggling like we did.

If this helps even one platform team make a better-informed decision, it was worth the vulnerability of sharing our failure.

cto_michelle · February 19, 2026, 9:01pm

Keisha, thank you for this incredibly honest post. This is exactly the kind of transparency our industry needs more of. Too many “success stories,” not enough “here’s what didn’t work and why.”

Your experience validates something I’ve been thinking about for a while: the right answer for platform engineering is deeply contextual.

The Other Side of the Same Coin

At my SaaS company, we went through a similar evaluation and made the opposite decision - we chose DIY Backstage and it’s working for us. But I think understanding WHY it works for us helps illuminate why it didn’t work for you.

Key differences:

We had an existing platform team (4 people dedicated to developer experience before we evaluated IDPs)

We were already at 120 engineers (economies of scale matter)

Our platform team had Backstage expertise (two engineers had implemented it at previous companies)

We had organizational maturity (clear service ownership, established golden paths, trusted platform team)

Your context was completely different - small team, rapid growth, building platform capability from scratch. In your situation, managed makes absolute sense.

The TCO Calculation You Got Right

Your math is sobering but accurate. I want to validate a few things and add some costs you might have even missed:

Additional hidden costs:

Training and knowledge transfer: What happens when your Backstage expert leaves? (Happened to us - took 3 months to recover)
Security maintenance: Monitoring CVEs, applying patches, security reviews (adds ~15% to maintenance cost)
Scaling costs: As you grow, infrastructure costs increase (our Backstage infra costs ~k/year at 120 engineers)
Tooling ecosystem: Monitoring, logging, backup, disaster recovery for Backstage itself

You quoted k total. My guess is the real number is closer to M+ when you account for everything.

When DIY Makes Sense

For organizations considering this decision, here’s my framework:

DIY Backstage Works When:

1. You have platform team capacity

Minimum 4-6 dedicated platform engineers
At least one with prior Backstage experience
Enough bandwidth to dedicate 1-2 people to maintenance

2. You have organizational maturity

Service ownership is clear
Golden paths already exist
Platform team has developer trust
Adoption culture exists

3. You have unique requirements

Regulatory constraints (can’t use cloud SaaS)
Extreme customization needs
Proprietary integrations that can’t be shared

4. You’re at sufficient scale

150+ engineers (rough threshold where economics shift)
Stable team size (not 3x’ing every year)
Long-term commitment (3+ year horizon)

Managed Solutions Work When:

1. You’re building platform capability

Small/new platform team
Rapid growth phase
Still establishing practices

2. You want to focus on differentiation

Platform engineers time better spent on domain-specific tools
Commodity infrastructure isn’t competitive advantage
Speed to value matters

3. Economics favor vendor

Team under ~150 engineers
Limited platform engineering headcount
High cost of maintenance relative to subscription

You checked all the boxes for “managed.” That was the right call.

The Pride/Ego Point

Your comment about ego hit me hard because it’s so true and so rarely acknowledged.

“The real reason we chose DIY wasn’t the cost math. It was ego. We’re a tech company. We’re engineers.”

I see this constantly in CTO circles. The assumption that “if we can’t build it ourselves, we’re not a real tech company.”

That’s nonsense.

Real technical leadership is knowing what NOT to build. It’s knowing where to create leverage vs where to accept commodity solutions.

Some of the best technical organizations I know:

Use hosted databases instead of running their own
Use managed Kubernetes instead of self-hosting
Use SaaS tools instead of building internal versions
Focus engineering on their actual product

The tech giants (Google, Netflix, etc.) can afford to build everything. Most companies aren’t tech giants.

Your decision to move to managed isn’t a failure. It’s strategic clarity.

The Adoption Rate Mystery

The 12% adoption rate is fascinating because it’s so consistent. You saw 12%, we see about 15%, every organization I talk to reports 10-20%.

This suggests the issue isn’t implementation quality - it’s something more fundamental about what portals are good for vs what we expect them to be good for.

Portals excel at:

Infrequent, high-value tasks (onboarding, incident response, architecture review)
Centralized visibility for leadership
Compliance and audit

Portals struggle at:

Daily development workflow
Replacing tribal knowledge
Making developers faster

We keep expecting portals to solve productivity problems. They solve coordination problems.

Maybe 10-15% adoption is actually RIGHT for the value portals provide. Maybe we’re measuring the wrong thing.

Strategic Advice for Your Migration

Since you’re moving to managed, here’s what I’d focus on:

1. Don’t just lift-and-shift

This is your chance to rethink what you actually need. Don’t recreate your DIY setup in managed environment.

Ask:

Which plugins do we actually need vs which did we add because we could?
Which custom integrations deliver real value?
What would we build differently if starting fresh?

2. Free up platform engineers for high-value work

You’re about to get back 1.5 FTE. Be deliberate about how you use that capacity.

Suggestion:

Golden path development
Developer productivity tooling
Self-service infrastructure
Observability and monitoring

3. Set clear success metrics

Define what “success” looks like BEFORE migration:

Onboarding time reduction
Time to first deployment for new services
Developer satisfaction scores
Deployment frequency

Track these as you migrate. Prove the ROI.

4. Communicate the why

Your engineering team invested in the DIY solution. Some will see managed as “giving up.”

Be transparent about:

The actual costs
The opportunity cost
What platform team will focus on instead
How this benefits developers

5. Negotiate hard with vendors

You have leverage:

You understand the space deeply
You have implementation experience
You’re a growth-stage company (valuable customer)

Get:

Volume discounts
Migration support
Custom integration assistance
Performance guarantees

The Maturity Question

Your point about organizational maturity is critical. You can’t technology your way out of organizational dysfunction.

I’d add: Platform engineering maturity should gate technology investment.

Stage 1 (10-30 engineers): Docs, templates, basic CI/CD
Stage 2 (30-100 engineers): Golden paths, self-service, clear ownership
Stage 3 (100-300 engineers): Service catalog, platform team, light portal
Stage 4 (300+ engineers): Full IDP, governance, metrics

You tried to go from Stage 1 to Stage 4. That rarely works.

Managed solutions can help you skip stages, but only if vendor handles the complexity. That’s literally what you’re paying for.

Final Thoughts

Keisha, your questions:

“How did you calculate TCO honestly?”

We did a spreadsheet: engineering time (fully loaded cost), infrastructure, tools, training, opportunity cost (est.), risk buffer (20%). Our 3-year TCO was ~.8M.

“At what team size does DIY Backstage become cost-effective?”

My rough threshold: 150+ engineers. Below that, managed is usually cheaper and better.

“How do you measure IDP ROI beyond ‘portal exists’?”

We track:

Time to first deployment (new engineers)
Mean time to discovery (finding service ownership)
Platform team ticket volume (lower = better self-service)
Developer NPS (quarterly survey)

None of these are perfect, but they’re directional.

Respect for the Decision

I have massive respect for your willingness to:

Do the honest math
Admit the mistake
Make the hard call
Share the story publicly

That’s leadership. That’s what platform engineering needs more of.

The market has standardized on Backstage. Good. Now we need to standardize on honest assessment of what works for whom and when.

Your post is a huge contribution to that conversation. Thank you.

eng_director_luis · February 19, 2026, 9:04pm

Keisha, this is valuable transparency. I want to add some questions and perspective from the financial services world, where our constraints are different.

The Compliance Dimension

At my Fortune 500 bank, we face a constraint you didn’t have to consider: regulatory requirements often prohibit cloud-hosted solutions.

Our data governance requires:

All systems on-premises or in our private cloud
Full audit trails of all access
Data residency in specific jurisdictions
No external SaaS access to production metadata

This means managed solutions like Spotify Portal and Roadie are not options for us, regardless of cost.

So while I completely agree with your decision for EdTech, I want to highlight that for regulated industries, the build vs buy question is sometimes answered by compliance before we even look at economics.

Questions About Your Evaluation

I’m curious about a few things that might help others in similar situations:

1. Which plugins caused the most pain?

You mentioned 12 plugins, with 3 abandoned and 2 with conflicts. Which categories? Was it:

CI/CD integrations (Jenkins, GitHub Actions)?
Cloud provider plugins (AWS, GCP)?
Observability tools (Grafana, Datadog)?
Custom business logic?

Understanding WHERE the plugin pain comes from helps others make better choices.

2. What drove the low adoption?

You had 12% daily active usage. Was this:

Feature gap (portal doesn’t do what developers need)?
UX problem (portal is too complex/slow)?
Culture issue (developers prefer existing workflows)?
Timing problem (portal came before golden paths)?

The answer changes what would fix it (and whether managed solution actually helps).

3. Did you evaluate alternatives to Backstage entirely?

You mentioned moving to Spotify Portal or Roadie (managed Backstage). Did you consider:

Port (different architecture, API-first)?
Cortex (opinionated, polished, expensive)?
No portal (focus on golden paths + API)?

Managed Backstage solves the maintenance burden but doesn’t solve the adoption problem if root cause is architectural or cultural.

Alternative Framing: What If Portal Isn’t The Solution?

Reading your post, I kept wondering: What if the problem isn’t DIY vs managed, but portal vs something else entirely?

Your developers want:

Fast onboarding
Clear ownership
Easy deployment
Good local dev experience

And portal adoption is 12% because it doesn’t directly solve those problems.

What if instead of:

Migrating to managed Backstage (k/year)

You invested that budget in:

Developer experience engineer (k/year)
Focus on golden paths, templates, automation
CLI tools and documentation
Self-service infrastructure

With no portal at all. Or a lightweight service catalog API with minimal UI.

Would adoption be higher? Would developer productivity improve more?

I don’t know the answer for your situation. But it’s worth asking.

The Hybrid Approach We Took

At my company, we ended up with a hybrid:

Core Backstage (self-hosted):

Minimal plugin set (6 plugins, all mature/maintained)
Service catalog as source of truth
API-first architecture

Heavy investment in integrations:

CLI tools that query service catalog API
IDE extensions for service discovery
Slack bots for common queries
Golden path templates with deep integration

Portal UI as optional interface:

Available for those who want it
Not positioned as primary tool
Mainly used by managers and during onboarding

This gives us:

Compliance (everything on-prem)
Developer flexibility (use portal or CLI or API)
Lower maintenance (fewer plugins)
Better adoption (meet developers where they are)

Cost: ~k/year (2.5 platform engineers + infrastructure)
Adoption: ~25% use portal; ~60% use CLI/IDE integration

Is this the right model for everyone? No. But it might be worth considering for organizations where managed isn’t option or portal adoption is challenge.

Advice for Your Migration

Since you’re moving to managed, my suggestions:

1. Deeply understand your adoption problem first

Before migrating, survey developers:

Why aren’t they using current portal?
What would make them use it?
What tools do they actually want?

If adoption problem is “portal is too slow to update” → managed helps
If adoption problem is “I don’t need a portal” → managed doesn’t help

2. Pilot with power users

Don’t migrate everything at once. Start with:

Platform team
Tech leads
Early adopters

Validate that managed solution actually improves experience before full migration.

3. Define success metrics beyond adoption

You might still see 12% daily usage on managed platform. That might be fine if:

Onboarding time decreases
Service ownership is clear
Incident response improves
Platform team delivers more value

4. Negotiate for hybrid model

Some vendors offer:

Core features in cloud
Custom plugins on-prem
API access for integrations

This could give you managed benefits with flexibility for custom needs.

The Sunk Cost Question

One thing I want to validate: You’re not falling for sunk cost fallacy in the other direction, right?

“We spent k on DIY, it didn’t work, so we must go managed” is sunk cost fallacy.

The right framing is: “Given where we are today, what’s the best path forward?”

Options include:

Managed Backstage (your choice)
Simplified DIY (fewer plugins, lighter maintenance)
Alternative platform (Port, Cortex, etc.)
No portal (golden paths + CLI)

I trust you evaluated all of these. Just making sure.

Final Thought: Build What Matters

Your conclusion is exactly right: commodity infrastructure isn’t competitive advantage.

For EdTech, your differentiation is:

Teaching tools
Student engagement
Learning analytics
Curriculum design

Spending platform engineering time on Backstage maintenance is waste. Spend it on:

Fast teacher onboarding
Reliable classroom tools
Great student experience
Education-specific tooling

Platform engineering should enable your mission, not consume resources.

That’s why managed makes sense for you. You’re freeing up 1.5 engineers to work on EdTech-specific platform needs instead of generic portal maintenance.

That’s strategic clarity. That’s good leadership.

Thanks for sharing the honest numbers. More orgs need to see the real TCO of DIY vs managed, not just the marketing promises.

alex_dev · February 19, 2026, 9:08pm

As a developer who’s been on the receiving end of platform team decisions, I want to offer a different perspective on this whole discussion.

Keisha, I really appreciate your honesty about the $850k investment and 12% adoption. But reading your post, I kept thinking: Did anyone actually ask us developers if we wanted a portal in the first place?

The Developer Reality

Here’s what my day actually looks like:

Morning:

git pull
Check CI status (GitHub)
Review PRs (GitHub)
Deploy to staging (kubectl + custom CLI)
Check logs (Datadog)

Afternoon:

Write code (VS Code)
Run tests locally (terminal)
Fix bugs (VS Code)
Deploy to prod (kubectl + custom CLI)
Check metrics (Datadog)

Portal usage: Maybe once a week to find who owns a service during an incident.

The portal exists. I have access to it. I just… don’t need it for 99% of my work.

What I Actually Want

You listed what developers want:

Fast deployments ✓
Easy rollbacks ✓
Clear ownership when things break ✓
Self-service infrastructure ✓
Good local development experience ✓

Here’s the thing: A portal doesn’t deliver any of those.

What WOULD deliver them:

Fast deployments: Better CI/CD pipeline, not a portal
Easy rollbacks: Good deployment automation, not a portal
Clear ownership: CODEOWNERS file + good docs, not necessarily a portal
Self-service infrastructure: Terraform modules + CLI, not a portal
Good local dev: Docker Compose + dev containers, not a portal

A portal might help me DISCOVER the deployment process. But it doesn’t make the deployment faster.

The Context-Switching Cost

Every time I need to use a portal, I have to stop coding, open browser, navigate, find what I need, then context switch back. That’s 2-3 minutes of friction.

If I can solve the same problem with grep or kubectl or asking in Slack, I’m doing that instead. Because it’s faster and keeps me in my workflow.

The Best Platform Teams I’ve Worked With

I’ve been at 4 companies. The best platform team didn’t have a portal at all.

What they had:

Amazing CLI tools: Fast, intuitive, well-documented
Great templates: Scaffolded everything I needed
Excellent docs: Clear, up-to-date, searchable
Responsive support: Fast Slack responses
Invisible infrastructure: Things just worked

I never once thought “I wish we had a portal.”

The WORST platform team had a fancy portal and terrible everything else. Nobody used the portal. Everyone complained.

The difference wasn’t the portal. It was priorities.

Unpopular Opinion: Managed Won’t Fix Adoption

You’re moving to managed Backstage. That will solve your maintenance problem. But I don’t think it will solve your adoption problem.

If developers aren’t using it because they don’t need it in their daily workflow, managed doesn’t help.

You’re fixing the wrong problem.

What I’d Recommend Instead

Survey developers first: What actually slows you down?
Invest in golden paths: Make the right thing the easy thing
Build great CLI tools: Meet developers where they work
Make docs excellent: Searchable, accurate, helpful
Portal as option: Available but not mandatory

You might still have 12% daily usage. That might be the right number.

Final Plea

Please talk to developers before investing in major platform decisions.

Not “here’s what we’re building” but “what slows you down? what do you wish existed?”

Build for us, with us. Not for us, despite us.

maya_builds · February 19, 2026, 9:08pm

Oh Keisha, this hits close to home. Like, uncomfortably close.

I built a failed startup. Spent 2 years building the “wrong thing” before we ran out of runway. Reading your post felt like looking in a mirror.

The Pattern I Recognize

Your story follows the exact same pattern as my failed startup:

My startup:

Saw a gap in the market
Built what we thought was “best practice”
Invested heavily in features we thought users needed
Launched to… crickets
Never stopped to ask: do they actually want this?

Your platform team:

Saw a need (service catalog)
Built what industry says is best practice (Backstage)
Invested heavily
Deployed to… 12% adoption
Finally asking: do developers actually want this?

Same pattern. Different domain.

User Research Would Have Saved You $800k

This comes from love: Did you do user research before building?

Not “hey we’re building a portal, what features?”

But actual UX research:

Shadow developers for a full day
Watch where they get stuck
Ask what frustrates them
Validate that a portal would help

If you’d done this, you probably would have discovered:

Developers don’t context-switch to portals during flow
Service discovery happens via Slack or grep
Onboarding docs matter more than browsable catalog
Deployment speed matters more than discoverability

Design Thinking for Platform Engineering

Here’s the framework we use in design (that platform teams should use):

Empathize: Deeply understand user needs
Define: Clearly articulate the problem
Ideate: Generate multiple solutions (portal is ONE option)
Prototype: Build lightweight versions to test
Test: Validate before full build

Most platform teams skip steps 1, 2, 4, and 5.

What Managed Won’t Fix

Managed Backstage fixes:

Maintenance burden
Feature velocity
Upgrade pain

Managed Backstage doesn’t fix:

Adoption (if problem is “don’t need it”)
UX (if developers prefer CLI)
Value proposition

You’re fixing the “how we build it” problem. You’re not fixing the “should we build it” problem.

What I’d Do Before Migrating

1. Deep user research (2-4 weeks)

Interview 15-20 developers
Understand why adoption is 12%
Validate that portal is the solution

2. Explore alternatives (2-4 weeks)

Prototype CLI tools
Prototype better docs
Test which approach developers prefer

You might still land on managed Backstage. But you’d know WHY.

That 12% Might Be OK

What if 12% is actually the right number?

If portal is:

Critical for onboarding (100% of new engineers)
Valuable for incidents (100% of on-call)
Optional for daily development (5-10%)

Then measure success by:

Time to onboard
Time to resolve incidents
Developer satisfaction

Not by daily active usage.

Final Thought

Whatever you decide: Talk to your developers first.

In 1-on-1 conversations. In observation sessions. In real research.

Build what they need, not what industry says they need.

That’s the lesson I learned the expensive way.