Neither Pure Build Nor Pure Buy: The Hybrid Platform Strategy That Actually Worked

cto_michelle · March 18, 2026, 12:11pm

I want to share a decision that initially felt like a compromise but turned out to be the best choice we could have made.

18 months ago, we faced the classic build vs buy debate for our internal developer platform. Pure build felt too expensive and risky. Pure buy felt too constraining.

We chose a hybrid model. It worked brilliantly.

The Context

Company: Mid-stage SaaS, 220 engineers
Challenge: Developer productivity was becoming a bottleneck as we scaled
Stakeholders: Engineering wanted control, Finance wanted predictability, Developers wanted speed

The Pure Options (And Why They Failed Our Needs)

Pure Build (Self-Hosted Backstage):

Complete control
Unlimited customization
$1.2M+ annual cost
18+ month timeline
Maintenance burden
TypeScript skills gap

Pure Buy (Fully Managed):

Fast time to value
Predictable costs
Vendor dependency concerns
Data sovereignty questions (we’re in financial services)
Customization limits for compliance workflows
Engineering team resistance

Neither option satisfied all stakeholders. We needed a third path.

The Hybrid Solution We Implemented

Foundation (Buy): Humanitec for IDP baseline

Portal UI and design system
Service catalog and discovery
Authentication and RBAC
User management
Basic workflow engine
Infrastructure integrations

Custom Layer (Build): Our differentiation

Golden path templates (our tech stack and patterns)
Deployment workflow automation (our processes)
Custom compliance checks (our regulatory requirements)
Cost allocation dashboard (our business logic)
Internal tool integrations (our legacy systems)
Security policy enforcement (our requirements)

The Numbers

Cost Structure:

Humanitec: $120K/year (220 engineers, enterprise plan)
Platform team: 3 engineers ($450K/year fully loaded)
Total: $570K/year

Compare to alternatives:

Pure DIY: $1.1M/year (6 engineers + infrastructure)
Savings: $530K/year = 93% ROI

Timeline:

Production-ready in 4 months (vs 18+ for DIY)
First golden path shipped in 6 weeks
78% developer adoption in 6 months

What We Buy (The Commodity Infrastructure)

We didn’t build:

Portal and UI → Humanitec provides polished, accessible, mobile-ready interface

Would have taken 4-6 months to build
Requires ongoing design and frontend engineering
Professional quality out of box

Catalog System → Humanitec handles service discovery, metadata, search

Would have taken 2-3 months to build
Requires database design, indexing, pagination
Scales automatically as we grow

Authentication & RBAC → Humanitec manages user auth, permissions, SSO

Would have taken 6+ months to build securely
Requires security expertise, audit trails, token management
Compliance-ready out of box

Core Infrastructure → Humanitec manages hosting, monitoring, scaling, uptime

Would require 1-2 FTEs ongoing
Database maintenance, infrastructure ops, incident response
99.9% SLA without our effort

What We Build (The Differentiator)

We focused engineering capacity on:

Golden Path Templates:

Service scaffolding for our microservices architecture
Terraform modules for our AWS patterns
CI/CD pipeline templates for our deployment workflows
Business value: New services onboard in 30 minutes vs 8 hours

Deployment Automation:

Custom approval workflows for our compliance requirements
Integration with our change management system
Automated testing gates specific to our quality standards
Business value: 3x deployment frequency, 60% fewer incidents

Cost Visibility Dashboard:

Per-service cost tracking connected to our AWS billing
Custom cost allocation by team and project
Budget alerts configured to our financial planning
Business value: $45K/month in cost optimizations identified

Compliance Automation:

Security policy checks for our regulatory requirements (SOC2, PCI)
Automated evidence collection for audits
Custom guardrails for data handling
Business value: 80% faster compliance verification

Legacy System Integration:

Connector to our mainframe system (yes, we still have one)
Integration with our custom ticketing system
Data sync with our HR system for team structures
Business value: Single source of truth across tools

The Key Insight: Buy Undifferentiated, Build Competitive Advantage

Ask yourself: “Does this capability differentiate us in the market?”

Portal UI? No. Every company needs a portal. UIs don’t differentiate.
Service catalog? No. Catalog is table stakes.
Authentication? No. Security is critical but not unique.

Our service onboarding process? YES. Encodes our architecture decisions, tech choices, quality standards.
Our deployment workflows? YES. Reflects our compliance requirements and operational maturity.
Our cost allocation logic? YES. Maps to our business model and team structure.

Buy what every company needs. Build what makes you unique.

Integration Architecture (Technical Details)

For engineers wondering “how do you integrate custom work with managed platform”:

Humanitec’s Plugin System:

Follows Backstage plugin architecture (open standard)
Plugins written in TypeScript (standard web tech)
APIs for extending catalog, workflows, UI
Can develop locally, deploy to managed environment

Our Custom Plugins:

cost-dashboard: React app, queries AWS Cost Explorer API
compliance-checker: Backend service, integrates with security tools
golden-path-generator: Templates + wizards for service creation
legacy-connector: Adapter layer to mainframe APIs

Safety Net:

Plugins are open source compatible
If we ever need to migrate, plugins work on self-hosted Backstage
We’re not locked into Humanitec’s proprietary system

The Cultural Win

Engineering team was satisfied:

They built meaningful capabilities, not framework code
Solved organizational problems, not React debugging
Saw direct impact on developer productivity
Shipped features monthly, not quarterly

Finance team was satisfied:

Clear cost structure: $120K platform + $450K team = $570K total
93% ROI vs DIY option
Predictable annual costs
Measurable productivity gains

Developers were satisfied:

Polished portal experience (professional quality)
Fast onboarding (30 minutes to new service)
Reliable automation (deployments work consistently)
78% adoption rate (high satisfaction)

Results After 12 Months

Productivity gains (measured via surveys + telemetry):

Service onboarding: 8 hours → 30 minutes (94% reduction)
Deployment time: 45 minutes → 8 minutes (82% reduction)
Finding documentation: 15 min/day → 2 min/day (87% reduction)
Time saved per developer: ~4 hours/week

Financial impact:

220 engineers × 4 hrs/week × $75/hr × 48 weeks = $3.2M annual productivity gain
Platform cost: $570K/year
Net benefit: $2.63M/year = 461% ROI

Positive ROI in 12 months. Paid for itself 4.6x over.

Why Isn’t Hybrid Discussed More?

I think the platform engineering discourse has a false dichotomy problem:

"Build vs Buy" frames it as binary choice.

Reality: It’s a spectrum from pure DIY to pure managed.

Most organizations should be somewhere in the middle:

Buy the infrastructure layer (commodity)
Build the capability layer (differentiation)

But industry narratives push extremes:

"Build everything! Own your destiny!"
"Buy everything! SaaS solves all problems!"

Hybrid is the pragmatic middle ground that satisfies technical, financial, and organizational needs.

For Teams Evaluating This Decision

Framework for deciding what to build vs buy:

Capability	Commodity?	Control Need	Vendor Quality	Skill Match	Decision
Portal UI	Yes	Low	High	No	Buy
Catalog	Yes	Low	High	Partial	Buy
Auth/RBAC	Yes	Medium	High	No	Buy
Golden Paths	No	High	N/A	Yes	Build
Workflows	Hybrid	High	Medium	Yes	Build on top
Integrations	Hybrid	Medium	Low	Yes	Build

If “Commodity=Yes” and “Vendor Quality=High”: Buy it
If “Commodity=No” and “Skill Match=Yes”: Build it
Everything else: Evaluate case by case

What We’d Do Differently

Honestly? Not much. The hybrid approach has been the right call.

If anything, we’d have started with managed platform even sooner instead of debating for 6 months.

Questions for the Community

Are others using hybrid approaches? I don’t see this discussed much in platform engineering circles.
How do you decide the boundary between “buy” and “build”?
What’s your experience with plugin architectures on managed platforms? Do they provide enough flexibility?
For those who went pure DIY or pure managed, would you reconsider a hybrid?

TL;DR: We chose hybrid model—buy Humanitec for foundation, build custom capabilities on top. Cost $570K/year vs $1.1M for DIY. Production in 4 months vs 18+. 78% adoption, 461% ROI in year one. Engineering team energized, finance team happy, developers productive.

Sometimes the compromise is the best solution.

eng_director_luis · March 18, 2026, 12:14pm

This is exactly the conclusion we reached after our 18-month DIY experiment. Your hybrid model maps perfectly to where we landed.

The Boundary Decision Framework

You asked “how do you decide the boundary between buy and build?” Here’s our framework:

Buy anything in Backstage core capabilities:

Portal infrastructure and UI components
Service catalog system and search
Authentication and permission systems
User management and teams
Plugin hosting and runtime
Core API and data models

Build anything organization-specific:

Golden path templates (your tech stack)
Workflow automation (your processes)
Custom dashboards (your business logic)
Internal integrations (your legacy systems)
Compliance automation (your requirements)

The litmus test: “Could another company use this exact capability, or is it specific to our organization?”

If it’s generic → Buy it
If it’s specific → Build it

Integration Architecture Questions

Your plugin approach is smart. We chose Roadie for similar reasons—plugin system matches open-source Backstage.

Technical details:

Develop plugins locally using Backstage dev environment
Test against Roadie staging environment
Deploy to production via their plugin upload mechanism
Version control: plugins in our monorepo, CI/CD for plugin releases

Development workflow:

Engineer builds feature as Backstage plugin (TypeScript/React)
Tests locally against mock data
PR review like any other code
CI runs tests, builds plugin bundle
Deploy to Roadie staging for integration testing
Promote to production

No different from developing any other code. Just deployed to managed platform instead of our infrastructure.

Cost Comparison Deep Dive

Your K/year vs our K/year (Roadie K + 4 engineers):

Why the difference?

You optimized team size (3 engineers vs our 4)
Your engineers fully focused on capabilities (our 4 split capacity with some maintenance)
Humanitec’s enterprise pricing was better for your size

Our 3-year projection now that we’re optimized:

Roadie: K/year (we scaled to 200 devs)
Platform team: 3 engineers = K/year
Total: K/year

ROI calculation (similar to yours):

200 devs × 4 hrs/week saved × /hr × 48 weeks = .88M productivity gain
Platform cost: K
Net benefit: .33M/year = 427% ROI

The pattern is clear: Hybrid delivers 400-500% ROI consistently.

What This Enabled For Our Team

Before hybrid (DIY phase):

80% time on maintenance (React debugging, upgrades, plugin compatibility)
20% time on capabilities
Team morale: 4/10 (stuck in maintenance treadmill)

After hybrid (managed + build):

10% time on vendor relationship (feature requests, bug reports, config)
90% time on capabilities (golden paths, automation, integrations)
Team morale: 9/10 (building meaningful features)

The morale shift was immediate and dramatic.

Engineers who were frustrated and looking to leave are now energized and engaged. They’re solving real organizational problems instead of debugging framework issues.

Retention impact: Zero turnover in 12 months post-migration (vs 2 engineers left during DIY phase).

Your 78% Adoption Rate

This is impressive and validates the approach. Our adoption:

3 months: 45%
6 months: 72%
12 months: 89%

Drivers of high adoption:

Polish: Managed platform UX is professional quality
Reliability: Doesn’t break, doesn’t have downtime
Value: Golden paths actually save time
Speed: Features ship monthly, not quarterly

Contrast with DIY phase:

Adoption was ~35% after 18 months
Developers avoided the portal (buggy, slow, incomplete)
Platform team was blamed (even though problem was structural)

Adoption is the ultimate metric. K with 78% adoption = great ROI. .1M with 35% adoption = wasted money.

To Answer Your Questions

Q: Are others using hybrid approaches?

Yes! We are, and I’ve talked to 5+ other platform teams who’ve landed on similar models:

Spotify uses managed Backstage hosting (Roadie) for some teams
Several fintech companies use Humanitec + custom plugins
Pattern: Buy foundation, build differentiation

But you’re right—it’s not discussed enough. Industry discourse is too binary.

Q: How do you decide the boundary?

Framework above (generic = buy, specific = build) + ask “is this a competitive differentiator?”

Q: Plugin architecture flexibility?

Yes, plenty. Backstage plugin API is comprehensive:

Custom pages and UI components
Backend services and APIs
Catalog enrichment and processors
Workflow extensions

We’ve built 8 custom plugins on Roadie without hitting limitations.

Q: Would pure DIY/buy teams reconsider hybrid?

Based on our expensive learning: Absolutely, yes.

We wish someone had pitched hybrid 18 months earlier. Would have saved .5M and 14 months of pain.

product_david · March 18, 2026, 12:14pm

This is the business case I wish I’d seen earlier. Your ROI numbers and decision framework are incredibly helpful.

The Business Framing That Resonates

Your “buy commodity, build differentiation” frame is exactly what CFOs and exec teams need to hear.

When I presented platform investment to our board, they asked:

“Why are we spending money on this?”
“What’s the business impact?”
“How does this drive revenue?”

Your answer: .2M productivity gain from K investment = 461% ROI in year one.

That’s a better return than most product investments. That’s the language that gets buy-in.

How To Quantify Productivity Gains

You showed 4 hours/week saved per developer. How did you measure this?

I’m building the case for our organization and need the methodology:

Did you:

Survey developers before/after? (“How many hours/week on manual tasks?”)
Track telemetry? (Time to onboard service, deployment duration, etc.)
Estimate based on workflow improvements?
Some combination?

Specific questions:

Service onboarding 8 hours → 30 minutes: How did you measure the before state?
4 hours/week saved: Is this self-reported or calculated from time savings?
Developer satisfaction: How did you track this?

I want to use your approach but need it to be defensible to our CFO.

The Go-to-Market Challenge

How did you pitch this internally?

To engineering: “We’re buying foundation so you can focus on building capabilities that matter.”

To finance: “461% ROI, measurable productivity gains, predictable costs.”

To exec team: “Platform investment enables 3x team scaling without 3x coordination overhead.”

Is that roughly how you framed it?

The Decision Matrix

Your “what to build vs buy” table is brilliant. I’m adapting it for our decision:

Capability	Commodity?	Control Need	Vendor Quality	Our Skills	Decision
Portal UI	✓	Low	High	Weak	Buy
Catalog	✓	Low	High	Medium	Buy
Auth/RBAC	✓	Medium	High	Weak	Buy
Docs System	✓	Low	High	Medium	Buy
Golden Paths	✗	High	N/A	Strong	Build
Deploy Automation	Hybrid	High	Medium	Strong	Build
Cost Dashboard	Hybrid	Medium	Low	Strong	Build
Compliance	✗	High	N/A	Strong	Build

Result for us: 50% pure buy, 50% build on top

This makes the hybrid case visually clear. “We buy infrastructure, build capabilities.”

The Adoption Risk Factor

Your 78% adoption in 6 months is the number that convinces me hybrid is right.

We’ve had internal tools with 20-30% adoption. They’re essentially wasted investments—engineers ignore them and use workarounds.

Question: What drove your adoption?

Mandated usage? (“You must use portal for deployments”)
Incentivized usage? (“Portal makes your life easier”)
Organic adoption? (“Developers chose to use it”)

And how did you measure it?

Active users per week?
Services in catalog?
Deployments via portal vs manual?

The Opportunity Cost Perspective

Your comparison is powerful:

DIY: .1M/year, 18-month timeline, 6 engineers maintaining + building
Hybrid: K/year, 4-month timeline, 3 engineers building

Delta: K/year + 14 months faster time to value

That K annual savings = 2-3 senior engineers working on revenue-driving features.

Over 3 years, that’s .6M + 6-9 person-years of product engineering capacity.

That’s the real business case: Not just platform cost, but what else we could do with the savings.

For Our Internal Pitch

I’m preparing this for our exec team. Would love your feedback on framing:

Slide 1: The Decision

Pure DIY: .9M, 18 months
Pure Buy: .5M, 2 months
Hybrid: .7M, 4 months ← Recommend

Slide 2: The Rationale

Buy commodity infrastructure (portal, catalog, auth)
Build competitive capabilities (golden paths, workflows, compliance)
Best of both: Control where it matters + speed where it doesn’t

Slide 3: The ROI

.7M investment
.2M productivity gain
188% ROI in year one

Slide 4: The Risk Mitigation

Vendor dependency: Plugin architecture gives exit path
Customization: Build capabilities on open platform
Timeline: 4 months vs 18 = 14 months of productivity gained earlier

Does this resonate? What would you add/change?

Final Questions

How long was buy-in process? From proposal to approval?
What objections did you face? Engineering culture? Finance concerns?
What metrics do you track now? How do you measure ongoing success?
Would you make same decision at different company sizes? (e.g., 50 devs vs 500 devs)

Your post should be required reading for anyone making this decision. Thank you for sharing the real numbers.

vp_eng_keisha · March 18, 2026, 12:14pm

The morale and retention angle of your hybrid approach is underrated. This is as much a people decision as a technical one.

Team Impact: Before and After

Your team morale shift—4/10 (DIY) to 9/10 (hybrid)—tells the whole story.

DIY phase problems:

Engineers stuck debugging React hooks instead of solving business problems
Maintenance treadmill → burnout
Visible impact delayed → low engagement
2 engineers left → recruiting + onboarding costs

Hybrid phase wins:

Engineers building meaningful capabilities
Direct impact on 220 developers → high engagement
Solving organizational problems → career growth
Zero turnover → retention savings

The retention ROI alone justifies hybrid approach.

Replacing 2 senior engineers = K+ (recruiting, onboarding, lost productivity, knowledge loss).

That’s 70% of your annual platform cost. If hybrid prevents one engineer from leaving, it pays for itself.

The “Interesting Work” Factor

What makes work engaging for platform engineers?

Maintaining frameworks (DIY):

Debugging TypeScript build issues
Chasing plugin compatibility
Monthly upgrade treadmill
Fighting same fires repeatedly

Building capabilities (Hybrid):

Designing golden paths that encode organizational knowledge
Solving workflow automation challenges
Measuring and improving developer productivity
Seeing direct impact on hundreds of engineers

Hybrid gives engineers problems they want to solve.

Recruiting Advantage

Your team composition (3 engineers) is lean because hybrid enables focus.

Recruiting pitch for hybrid approach:

"Join our platform team. You’ll build capabilities that accelerate 220 engineers:

Design golden paths that reduce service onboarding from hours to minutes
Build deployment automation that increases velocity 3x
Create cost visibility tools that enable data-driven optimization
Own platform capabilities end-to-end with direct impact

We use Humanitec for infrastructure, so you focus on solving organizational problems, not maintaining React apps. You’ll learn platform engineering, DevOps, and organizational system design—skills that transfer to any company."

vs DIY recruiting pitch:

"Join our platform team. You’ll work on our internal developer portal:

Maintain our fork of Backstage (TypeScript, React)
Debug plugin compatibility issues
Keep up with monthly framework upgrades
Build new features when time permits

You’ll learn Backstage internals and React/TypeScript—skills specific to this framework."

Which job gets better candidates?

The first one attracts senior engineers who want to solve meaningful problems. The second one attracts… framework enthusiasts?

Skill Development and Career Growth

Your engineers are developing transferable platform engineering skills:

Developer experience optimization
Workflow automation and integration
Organizational system design
Platform-as-product thinking
Measuring and driving productivity improvements

These skills apply to any company, any platform. If someone leaves your company, they’re marketable for platform roles anywhere.

vs DIY skill development:

Backstage framework internals
React/TypeScript for specific plugin architecture
Maintenance of open-source projects

These skills are framework-specific. Valuable only if next company also uses Backstage.

Career growth question engineers ask: “Will this role make me more marketable or more specialized?”

Hybrid approach = more marketable
DIY approach = more specialized (and niche)

The 3-Person Team Size

You optimized to 3 engineers. That’s impressive for 220 developers.

How is this sustainable?

My guess:

0.3 FTE: Vendor relationship management (feature requests, support, config)
0.5 FTE: Platform evangelism and support (helping developers use platform)
2.2 FTE: Building capabilities (golden paths, automation, integrations)

vs DIY team of 6:

2.5 FTE: Framework maintenance (upgrades, bugs, compatibility)
1.5 FTE: Infrastructure ops (hosting, monitoring, scaling)
2 FTE: Building capabilities

Hybrid delivers more capability delivery with fewer people.

Organizational Scalability

As you grow from 220 to 300 to 500 engineers:

Hybrid team scaling:

220 devs: 3 engineers
300 devs: 4 engineers (add capacity for more golden paths)
500 devs: 5-6 engineers (more capabilities, not more maintenance)

Platform team scales with capabilities, not maintenance.

DIY team scaling:

220 devs: 6 engineers (split between maintenance and capabilities)
300 devs: 8 engineers (more users = more support, more maintenance)
500 devs: 10-12 engineers (maintenance burden grows with usage)

Platform team scales with infrastructure complexity.

Your approach scales more efficiently. And hiring 3-4 strong engineers is easier than hiring 6-8.

Leadership Lessons

1. Optimize for team energy, not just cost

K savings is great, but energized team building meaningful features is priceless.

Burnt out team maintaining framework costs more in turnover, missed opportunities, and low morale than you save in licensing fees.

2. Career development is retention

Engineers stay when they’re learning and growing. Building capabilities develops transferable skills. Maintaining frameworks develops niche skills.

3. Team size isn’t a status symbol

Leading 3-person team building high-impact capabilities > Leading 6-person team maintaining infrastructure

Smaller focused team can outperform larger fragmented team.

To Answer Your Questions

Q: Are others using hybrid?

Yes! And it’s the approach I recommend to all VPs asking me about platform strategy.

But agree it’s not discussed enough. Most content is pure DIY advocates or pure SaaS advocates.

Q: How decide boundary?

Your framework (commodity = buy, differentiator = build) is what I use.

Add: “Does this grow my team’s skills in valuable directions?”

Q: Plugin flexibility?

From org design POV: Plugins give engineers ownership and impact without maintenance burden. That’s the sweet spot.

Q: Would DIY teams reconsider?

Every DIY team I talk to is considering managed options after 12-18 months of maintenance pain.

Hybrid is the evolution after learning the hard way.

Bottom Line

You optimized for team health, retention, and meaningful work—not just cost.

Result: Energized team, zero turnover, high adoption, 461% ROI.

That’s the definition of a successful platform strategy.

maya_builds · March 18, 2026, 12:14pm

Product design perspective: Your 78% adoption rate is the number that matters most, and it’s because hybrid optimizes for user experience quality.

Why Adoption Rates Tell The Whole Story

You can build the most powerful platform in the world, but if developers don’t use it, ROI is zero.

Your results:

DIY attempt: ~35% adoption (developers avoided buggy portal)
Hybrid approach: 78% adoption in 6 months (developers chose to use it)

What changed? Not just features. Product quality.

The UX Quality Advantage

Managed platform foundation (Humanitec):

Professional design system
Consistent interaction patterns
Accessible and mobile-ready
Fast, reliable, polished
Regular UX improvements

DIY platform (typical outcome):

Inconsistent UI components
Janky interactions
Desktop-only, no accessibility
Slow, breaks occasionally
UX improvements deferred (“we’ll fix it later”)

Developers compare your internal portal to tools they use daily: GitHub, Datadog, Linear, Vercel.

If your portal feels homemade compared to those, adoption will suffer.

Your Golden Paths Delivered Value Because Foundation Was Solid

Here’s what’s brilliant about your approach:

You didn’t waste time on:

Designing and building portal UI (6+ months)
Creating component library (3+ months)
Implementing search and pagination (2+ months)
Building authentication system (4+ months)

You focused on:

Service onboarding 8hrs → 30min (developers love this)
Deployment automation (developers love this)
Cost visibility (engineering leadership loves this)
Compliance automation (security team loves this)

Your platform engineers built features users actually wanted instead of infrastructure users tolerate.

Result: 78% adoption.

The Product Thinking That Drove Success

You treated internal platform as a product:

User research: Surveyed developers, tracked telemetry
Feature prioritization: Built what saves the most time
Quality bar: Professional UX (via managed platform)
Continuous improvement: Monthly feature releases
Metrics-driven: Measured adoption, time saved, satisfaction

vs DIY approach (common pattern):

“We know what developers need” (no user research)
“Build catalog first” (infrastructure-first, not user-first)
“We’ll improve UX later” (quality is deferred indefinitely)
“We’re too busy for feature work” (maintenance consumes capacity)
“Portal is done, move on” (no continuous improvement)

Your hybrid approach enabled product thinking.

Because you weren’t maintaining framework, you had capacity to:

Listen to users
Iterate on features
Measure impact
Improve continuously

The Adoption Flywheel

Good products create positive feedback loops:

Initial adoption → Users save time → Word spreads → More users adopt → More feedback → Better features → Higher adoption

Your 78% in 6 months shows this flywheel working.

vs DIY negative loop:

Low initial quality → Users avoid portal → Complaints spread → Adoption stalls → Platform team blamed → Morale drops → Quality declines further

We’ve all seen internal tools stuck in this death spiral.

The “Would You Use This?” Test

Here’s a question for teams considering DIY:

“If your internal portal were an external SaaS product, would customers pay for it?”

If answer is “not in current state,” then it’s not good enough for internal users either.

Your hybrid platform could be a product. It’s that polished.

Most DIY platforms couldn’t. They’re functional but not professional.

Visual Design Matters (More Than Engineers Think)

I know engineers think “devs don’t care about design, just functionality.”

That’s wrong.

Developers use beautifully designed tools daily:

GitHub (gorgeous dark mode, thoughtful interactions)
Vercel (clean, fast, delightful)
Linear (pixel-perfect, smooth animations)
Raycast (polished to perfection)

When internal tools look amateurish by comparison, developers notice and usage suffers.

Your managed foundation gave you professional design quality for free. Your custom features inherited that quality.

Result: Developers trust and use the platform.

The “Time To Delight” Metric

How long until a developer has a delightful experience with your platform?

Hybrid approach:

Day 1: Log in, see polished UI (immediate positive impression)
Week 1: Use golden path, create service in 30 minutes (“this is amazing”)
Month 1: Deploy self-service, see cost dashboard (“this is actually useful”)

DIY approach:

Day 1: Log in, see basic UI (“looks homemade”)
Week 1: Find documentation (“catalog is slow, search is broken”)
Month 1: Wait for features (“team is too busy fixing bugs”)

Delight drives adoption. Polish matters.

For Your Metrics Question

You asked about measuring adoption. Here’s what I’d track:

Quantitative:

Active users (weekly/monthly)
Services in catalog (coverage)
Deployments via portal (vs manual)
Golden path usage (self-service onboarding)
Time spent in portal (engagement)

Qualitative:

Developer satisfaction survey (quarterly)
NPS score (“Would you recommend portal to peers?”)
Anecdotal feedback (Slack comments, support tickets)

Your 78% adoption is probably:

78% of developers logged in monthly, OR
78% of services in catalog, OR
78% of deployments via portal

Either way, it’s high. Most internal tools get 40-60% at best.

The Recommendation I Give Designers

When design teams ask “Should we build our design system or use existing?”

Answer: “Buy the foundation (Material UI, Chakra, Radix), build the brand layer.”

Same principle as your platform strategy.

Don’t build buttons and inputs from scratch. Use a high-quality component library. Customize the brand, colors, and components specific to your product.

Your platform decision applies to design systems, CI/CD tools, monitoring, everything.

Buy commodity infrastructure. Build differentiation.

To Answer Your Question

Q: Are others using hybrid?

Yes! Every successful internal tool I’ve seen uses this pattern:

Buy foundation (Backstage, Retool, internal tool SaaS)
Build custom workflows and integrations

Q: Plugin flexibility enough?

From UX POV: Yes. Plugins let you create custom flows without compromising base quality.

Managed platform maintains polish, your plugins add functionality.

Q: Would pure DIY reconsider?

If they track adoption rates, they already are.

Low adoption = failed product, regardless of cost.

Your hybrid approach is the right model. It optimizes for user experience, team focus, and business impact.

That’s how you get 78% adoption and 461% ROI.