We Spent 600K Building Our Internal Portal with 10 Percent Adoption

General
1

This is the painful story I didn’t want to share in the other thread, but it needs to be said because I see teams making the same mistake we did.

We spent $600K and 14 months building our internal developer portal using self-hosted Backstage. Beautiful service catalog. Sleek UI. Comprehensive API documentation. Automated dependency mapping.

10% adoption after 6 months.

The build-vs-buy decision doesn’t matter if nobody uses what you built.

The Numbers That Hurt

Investment:

  • 5 platform engineers × 14 months × $9K/month = $630K
  • Infrastructure costs: $2K/month = $28K
  • Design contractor (3 months): $45K
  • Total: $703K

Return:

  • Target: 80% weekly active users (our definition of success)
  • Month 1: 8% WAU
  • Month 3: 12% WAU
  • Month 6: 10% WAU (actually went down as novelty wore off)

ROI: Spectacularly negative.

What Went Wrong: We Built Infrastructure, Not Product

Here’s the brutal truth: We treated the portal like an infrastructure project instead of a product.

Infrastructure mindset:

  • “Build it and they will come”
  • Success = deployment is stable
  • Users = anyone with login access
  • Feedback = opened a few Slack threads asking for input

Product mindset:

  • Adoption must be earned through value
  • Success = users choose your tool over alternatives
  • Users = people actively solving problems with your product
  • Feedback = continuous user research, interviews, usage analytics

We did infrastructure. We needed product.

The Adoption Killers We Ignored

1. We solved our problems, not developer problems

Platform team wanted centralized service ownership tracking (management problem). Developers wanted faster onboarding docs (their actual pain point). We built the former.

2. Portal competed with muscle memory

Developers already knew how to:

  • Find service ownership: Ask in #engineering-help Slack
  • Check deployment status: Look at DataDog
  • Find API docs: Search GitHub

Our portal required learning a new tool to do things they already knew how to do. Convenience beats comprehensive.

3. We measured deployment, not value delivery

Celebration when portal went live. No measurement of:

  • Time-saved per developer per week
  • Reduction in “where is X” Slack questions
  • Onboarding time for new engineers
  • Incident response time improvement

We had zero data proving the portal made developers more productive.

4. No forcing function for adoption

Portal was optional. Every feature was “nice to have.” Compare to:

  • GitHub: You must use it to commit code (forced)
  • Jira: PM blocks you if tickets aren’t updated (forced)
  • CI/CD: Code doesn’t deploy without it (forced)

Portal: “Here’s a tool. Try it out. Let us know what you think.” Optional tools stay optional.

The Backstage Paradox

Spotify reports 99% internal Backstage adoption. External companies average 10-15%.

What’s different?

  1. Spotify’s portal is their competitive advantage - They have product managers, designers, and continuous user research dedicated to it
  2. They built for their specific culture - Not trying to be generic framework
  3. They have forcing functions - Portal is tightly integrated into their development workflow
  4. Massive investment - 30+ people working on Backstage full-time

Your 3-person platform team self-hosting Backstage is playing a different game.

What We Should Have Done

Looking back with painful clarity:

Option 1: Managed Solution First

  • Get to production in 3-4 weeks instead of 14 months
  • Validate that portal concept drives adoption
  • If adoption is high, then consider self-hosting for customization
  • If adoption is low, saved 14 months of wasted engineering

Option 2: Lightest-Weight MVP Possible

  • Notion page with service catalog
  • 2 days of engineering time
  • Measure adoption: Do developers actually use centralized docs?
  • Build portal only if lightweight version proves demand

Option 3: Interview Developers First

  • “What blocks you from being productive?”
  • “How do you currently find service ownership info?”
  • “What tool do you wish existed?”
  • Build what they actually need, not what we think they need

We did none of the above.

The Question That Haunts Me

How do you force adoption vs earn adoption?

Forcing doesn’t work long-term:

  • Mandate usage → resentment + workarounds
  • Make it required for deployments → adds friction to critical path
  • Remove alternatives → developers find new workarounds

Earning is hard but sustainable:

  • Solve genuine developer pain
  • Make it 10x better than current solution
  • Start with one killer feature that’s obviously valuable
  • Expand from there

We never identified the killer feature. Service catalog wasn’t painful enough to justify learning new tool.

For Teams Considering Self-Hosted Backstage

Before you commit:

  1. Do user research first - Not “we talked to 3 people,” real user interviews
  2. Identify the killer feature - What’s the one capability that makes portal essential?
  3. Define adoption metrics upfront - What % usage = success? How will you measure?
  4. Build forcing function into design - How does portal become necessary, not optional?
  5. Assign product ownership - Someone owns adoption, not just uptime

Or just use a managed solution where vendor has already figured out adoption patterns across hundreds of companies.

The Real Cost

$600K is painful but recoverable. The real cost:

  • Opportunity cost: What could 5 engineers have built for product in 14 months?
  • Team morale: Platform team feels like failure after massive investment
  • Organizational trust: Leadership now skeptical of future platform initiatives
  • Sunk cost trap: Hard to admit failure and switch to managed after that investment

The build-vs-buy decision matters less than the adoption-vs-abandonment decision.

A $200K managed portal with 75% adoption is infinitely better than a $700K self-hosted portal with 10% adoption.

Who else has lived this? What broke your adoption—and how did you fix it (or did you)?

2

This is a textbook case of the “build it and they will come” fallacy that kills internal tools.

Product Management Lens: You Skipped Discovery

The pattern I see here is classic: Platform team identified a solution (portal) before validating the problem.

What should have happened:

  1. Problem discovery: Interview 15-20 developers: “What blocks you from being productive?”
  2. Prioritize pain points: Rank by frequency + severity
  3. Validate with lightweight MVP: Build simplest possible solution to test adoption
  4. Measure: Did simple solution get used? If yes, invest more. If no, you just saved $600K.

What actually happened: “We need a portal” → Build portal → Surprise, nobody uses it

The Service Catalog Assumption

You built service catalog because platform teams think service ownership tracking is critical. But did developers actually have that pain point?

Questions to ask:

  • How often do developers need to find service owners? (Daily? Weekly? Monthly?)
  • Whats their current workaround? (Slack? GitHub CODEOWNERS? Ask manager?)
  • Is current workaround painful enough to justify learning new tool?

My guess: Finding service owners was occasional problem, not daily blocker. Slack question took 30 seconds. Portal required learning interface, remembering URL, logging in. Higher friction than problem warranted.

Managed Solutions Solve the Product Problem

This is why managed solutions often win: Theyve done user research across hundreds of companies.

Port, Cortex, OpsLevel—they know:

  • What features drive adoption (service catalog + on-call + incident runbooks)
  • What UI patterns work (fast search, mobile-friendly)
  • What integrations matter (GitHub + PagerDuty + Slack)
  • How to onboard users (templates, tutorials, progressive disclosure)

Your platform team had to learn all of this from scratch. And by the time you learned it, youd already spent $600K.

The Forcing Function Question

You asked: “How do you force adoption vs earn adoption?”

My answer: Don force. Find the forcing function naturally.

Examples:

  • Incident response: Portal has on-call schedules + runbooks → Naturally used during incidents
  • Onboarding: Portal is official getting-started guide → New hires must use it
  • Service creation: Template scaffolding tool requires portal → Used when spinning up services

If you can identify natural forcing function, you probably don have product-market fit for portal.

What to Do Now

You have two options:

Option 1: Fix Adoption

  • Treat portal as product, not infrastructure
  • Hire PM or assign product owner
  • Do user interviews to find actual pain points
  • Rebuild features around those pain points
  • Measure time-saved, not logins

Option 2: Cut Losses

  • Migrate to managed solution
  • Get high adoption in 4 weeks instead of grinding for months
  • Admit sunk cost is sunk
  • Redeploy 5 engineers to product work

Option 2 is usually correct answer when adoption is this low after 6 months.

The Lesson for Others

Before building any internal tool:

  1. Validate problem with user research
  2. Test solution with lightweight MVP
  3. Measure adoption before scaling investment
  4. Ask “build vs buy” only AFTER validating problem

Otherwise you
e optimizing the solution to a problem nobody has.

3

This hits hard because Ive seen this exact pattern play out. The tactical mistake was treating portal as infrastructure. The strategic mistake was organizational structure.

Leadership Perspective: Who Owned Adoption?

Platform team optimized for uptime and features. Nobody optimized for adoption.

The question that reveals everything: Who had adoption as their OKR?

  • Platform team OKR: “Launch portal with service catalog, API docs, and monitoring integrations”
  • Reality needed: “Achieve 60% WAU within 6 months”

Platform teams are infrastructure teams. They think in terms of availability, latency, correctness. They don think like product managers.

The Org Structure Problem

At my current company, our internal developer platform reports through engineering, but we have:

  1. Product owner (0.5 FTE from product org)
  2. Designer (0.3 FTE shared with design systems)
  3. Platform engineers (3 FTE for infrastructure)
  4. Developer advocate (0.5 FTE for adoption, training, evangelism)

Total: 4.3 FTE, but critically, someone owns adoption as their job.

Your setup: 5 platform engineers, zero product ownership. Recipe for beautiful infrastructure nobody uses.

The Mandate vs Earn Trap

You asked about forcing adoption. Heres my take:

Mandate backfires:

  • Resentment
  • Workarounds
  • Minimum compliance (check box, never return)
  • Trust erosion with platform team

Earn is slow but sustainable:

  • Find one team with acute pain
  • Solve their problem perfectly
  • They become advocates
  • Other teams see value, adopt voluntarily
  • Adoption compounds

But theres a third option: Design for necessary.

Portal isn mandated, but it becomes necessary because:

  • Scaffolding templates only accessible through portal
  • Service registry (not catalog—registry) is source of truth for deployment configs
  • On-call schedule determines who gets paged

Not “you must use portal,” but “portal is how these critical workflows work.”

The Success Pattern: Start With One Killer Feature

Our portal adoption curve:

  • Month 1-3: Service catalog only. 15% adoption. Meh.
  • Month 4: Added on-call schedule integration with PagerDuty. 45% adoption (anyone on-call uses it).
  • Month 6: Added incident runbooks with one-click escalation. 70% adoption (used during every incident).
  • Month 9: Added service scaffolding templates. 85% adoption (used when creating services).

The difference: Each feature solved acute pain, not theoretical problem.

What You Should Do Now

Hard truth: 10% adoption after 6 months is a failing grade. You have two realistic paths:

Path 1: Treat As Product (High Risk)

  • Assign product owner (not platform eng—actual PM)
  • Do 30 user interviews in next 2 weeks
  • Find the one problem thats painful daily
  • Rebuild around that problem
  • Measure weekly: Are developers using it?
  • Give this 3 months. If adoption doesn hit 40%, you have your answer.

Path 2: Cut Losses (Lower Risk)

  • Evaluate managed solutions (Port, Cortex, OpsLevel)
  • Pick one, migrate in 4-6 weeks
  • Redeploy platform eng time to product
  • Measure managed solution adoption—vendors often hit 60-70% in first quarter

Path 2 feels like admitting defeat. But sunk cost is sunk. The question is: Whats best use of next 12 months?

Building adoption from 10% → 60% is harder than migrating to managed solution with proven adoption patterns.

The Real Lesson

Platform is product.

If you
e building internal tools, you need product discipline:

  • User research
  • Product-market fit
  • Adoption metrics
  • Continuous iteration

Platform engineering is not just infrastructure engineering. Its product engineering for internal customers.

4

From the designer/user perspective, I want to highlight something that might be painful to hear: Your portal probably had terrible UX, and that killed adoption more than any strategic mistake.

The Design Gap Nobody Talks About

You mentioned hiring a design contractor for 3 months. Let me guess:

  • Months 1-11: Platform engineers build features with default Backstage UI
  • Month 12: “Lets make it pretty” → Hire contractor
  • Month 12-14: Contractor makes minor UI tweaks, adds branding, maybe custom theme
  • Launch: Looks… fine. Not great, but functional.

Problem: Design was afterthought, not foundation.

Why Self-Hosted Backstage Has Low Adoption

Backstage gives you framework, not design. Every self-hosted Backstage Ive seen looks the same:

  • Default Material UI components
  • Sidebar with 15 navigation options (too many)
  • Tables with 12 columns (information overload)
  • Search thats technically functional but UX is clunky
  • Mobile? Forget it.

Compare to managed solutions:

They hire design teams because UX IS their competitive advantage:

  • Port: Clean, modern, fast
  • Cortex: Intuitive navigation, progressive disclosure
  • OpsLevel: Mobile-first design, rapid search

The Adoption Killer: Competing With Consumer-Grade UX

Developers use:

  • GitHub (beautiful, fast, obsessed with UX)
  • Notion (delightful, addictive UX)
  • Slack (frictionless, muscle-memory UI)
  • DataDog (powerful but accessible)

Your portal:

  • Slow (3-5 second load times are unacceptable)
  • Confusing (where do I find X?)
  • Ugly (looks like enterprise software from 2015)
  • Clunky (every interaction takes 3 clicks)

Developers don use tools that feel bad.

The Questions You Didn Ask

Before building, did platform team ask:

  1. What does delightful developer experience feel like?
  2. Whats our target for page load time? (Under 1 second?)
  3. How many clicks to complete primary user task? (Target: 1-2)
  4. Is this usable on mobile?
  5. Did we do usability testing with actual developers?

My guess: No, no, didn measure, no, no.

Managed Solutions Solve the UX Problem

This is why I advocate for managed:

Port has:

  • Design team (6+ people)
  • Product managers who obsess over UX
  • User research across hundreds of companies
  • A/B testing on flows
  • Continuous UI iteration

Your 3-person platform team:

  • Zero designers
  • No product managers
  • Infrastructure engineers doing UX (not their skillset)
  • No user testing
  • “Ship it and theyll adapt”

You can compete on UX without design resources.

What Would Have Helped

Option 1: Hire designer from Day 1

  • Not month 12. Month 1.
  • Designer participates in architecture decisions
  • UX drives feature prioritization
  • Usability testing every sprint
  • Budget: $150K/year, but actually gets used

Option 2: Use managed solution

  • Vendor has solved UX problem
  • You get beautiful product without building it
  • Platform team focuses on integrations, golden paths, adoption

The Uncomfortable Truth

You spent $600K but probably:

  • Zero user research budget
  • Zero usability testing
  • Zero A/B testing
  • Zero design iteration
  • $45K design contractor as afterthought

You built infrastructure, not experience.

Developers don adopt infrastructure. They adopt experiences.

If You

e Rebuilding

Start with design:

  1. User research: What makes developers feel productive? What delights them?
  2. Design mocks first: Don write code until design feels right
  3. Usability testing: Watch 5 developers try to complete tasks. Where do they get stuck?
  4. Iterate on UX: Polish before shipping
  5. Measure delight: NPS, “would you recommend this tool?”

Or just buy managed solution where someone else has already done this work.

The Real Reason Spotify Succeeds

Spotifys Backstage has 99% adoption not just because of forcing functions, but because it feels good to use.

They have:

  • Dedicated designers
  • Product managers
  • User researchers
  • Continuous UX iteration

Your self-hosted Backstage had infrastructure engineers trying to do design. Thats why adoption failed.