90% Have Internal Platforms, But DIY Is Dead: How Should We Think About Platform Engineering in 2026?

vp_eng_keisha · March 22, 2026, 4:36am

The 2024 DORA report dropped a stat that should fundamentally change how we think about platform engineering:

90% of enterprises now have internal developer platforms.

Let me repeat that: Ninety percent.

Platform engineering went from “emerging practice” to “table stakes” in about 3 years. And now we’re at an inflection point that’s going to reshape the entire discipline.

The DIY Era Is Dead

Here’s the shift: In 2021, if you wanted an internal platform, you built it. There weren’t many options. Backstage was new, managed solutions barely existed, and platform engineering meant hiring a team to build everything from scratch.

In 2026, that approach is dead.

Why? Because the build-everything approach doesn’t scale, costs too much, and delivers value too slowly. The market has spoken: Integration beats implementation.

What Changed

Three things converged:

1. Mature OSS Frameworks

Backstage reached production-readiness
Port, Cortex, and others launched managed offerings
The “build from scratch” justification evaporated

2. Platform-as-a-Service Emerged

Managed solutions went from “basic” to “comprehensive”
Customization improved dramatically
Price points became competitive with self-hosting

3. Economic Reality Hit

Companies realized the true cost of building (see David’s thread)
Opportunity cost became impossible to ignore
“Free” Backstage cost more than paid alternatives

The New Platform Paradigm

The successful platform teams I’m seeing aren’t building platforms anymore. They’re curating platforms.

Here’s what that means:

Old model (DIY):

Build service catalog from scratch
Build documentation system
Build deployment portal
Build monitoring dashboard
Build everything, own everything

New model (Integration):

Adopt managed service catalog (Cortex, Port)
Integrate existing docs (Notion, Confluence, GitHub)
Connect existing deployment tools (Argo, Spinnaker)
Link existing monitoring (Datadog, New Relic)
Build only what’s truly unique to your org

The value isn’t in building. It’s in creating cohesive experience from existing tools.

What Platform Teams Actually Do Now

I’m watching this shift happen in real-time. Platform teams are becoming:

1. Integration Architects

Connect disparate tools into unified experience
Build thin glue layer between systems
Focus on data flow, not feature building

2. Experience Curators

Choose best-in-class tools for each need
Design workflows that span multiple tools
Own the developer experience, not the technology

3. Enablement Teams

Help product teams adopt platform tools
Create self-service patterns
Measure and improve adoption

4. Vendor Managers

Evaluate build vs buy decisions
Negotiate contracts
Manage tool sprawl

Notice what’s missing? Building platforms from scratch.

The FinOps Integration Challenge

Here’s a new wrinkle nobody’s talking about: FinOps integration.

Platform teams are now responsible for cost visibility and optimization. But they’re not building cost tools—they’re integrating them.

The challenge:

Kubecost for container costs
CloudHealth for cloud costs
Datadog for observability costs
GitHub for CI/CD costs

How do you give developers unified view of “what does my service cost to run”?

Answer: Integration layer that pulls from all these sources.

This is the new platform engineering: making sense of tool sprawl, not adding to it.

The AI Integration Wild Card

And then there’s AI. Every vendor is adding AI features:

GitHub Copilot for code
Datadog AI for anomaly detection
Various AI tools for docs, testing, deployment

Platform teams now need to:

Evaluate which AI tools to adopt
Integrate them into workflows
Measure their impact
Manage the cost (AI tokens aren’t cheap)

This is happening faster than anyone expected. Platform teams that are still building from scratch are going to get left behind.

What Dies, What Survives

What’s dying:

Building platforms from scratch
Multi-year platform initiatives
Platform teams of 10+ engineers
“We’ll build it because we’re special” mentality

What’s surviving:

Integration-focused platform teams
Small teams (3-5 people) with product mindset
Continuous evolution based on user feedback
Pragmatic build-vs-buy decisions

What’s emerging:

Platform-as-a-service dominance
AI-powered developer tools
FinOps as core platform concern
Developer experience as measurable metric

The Critical Question

Here’s what I’m wrestling with:

If 90% of companies have platforms, and DIY is dead, what’s the actual job of a platform team in 2026?

Is it:

A) Building tools that are unique to our company?

Requires identifying what’s genuinely unique (rare)
High risk, high cost
Only makes sense at massive scale

B) Integrating best-in-class tools into cohesive experience?

Lower risk, faster time-to-value
Requires different skills (product, integration, UX)
More sustainable long-term

C) Enabling teams to self-serve from ecosystem of tools?

Lightest touch
Requires excellent documentation and support
Scales better than building

I’m increasingly convinced the answer is B and C together.

Build only what’s genuinely unique (maybe 10% of your platform). Integrate the other 90%. Enable teams to self-serve from the integrated ecosystem.

The Skills Gap

This shift requires different skills than 2021 platform engineering:

Then: Deep technical skills, systems architecture, full-stack development

Now: Product thinking, API integration, vendor evaluation, UX design, change management

Most platform teams are still hiring for “then.” They need to hire for “now.”

My Prediction for 2027

By this time next year:

80% of new platforms will be built on managed solutions, not OSS frameworks
Platform teams will shrink from 8-12 people to 3-5 people
Build-from-scratch will be limited to enterprises with >1000 engineers
FinOps will be integrated into every major platform solution
AI tooling will be table stakes, not experimental

The platform engineering discipline isn’t dying—it’s maturing. And maturity means doing less building, more integrating.

What I Want to Know

For those running platform teams:

Is your platform team’s job building tools or enabling an ecosystem?

Are you spending 80% of your time building, or 80% integrating and enabling?

If it’s the former, how do you justify that in 2026 when there are managed solutions for almost everything?

And if it’s the latter, what skills are you hiring for? Because “platform engineer” might need to mean something very different than it did 3 years ago.

The 90% stat tells us platforms won. Now we need to figure out what platforms become.

cto_michelle · March 22, 2026, 4:36am

Keisha, this is the conversation we should have had 18 months ago before we spent $3M building Backstage.

The Painful Validation

Your prediction about the shift from building to integrating? We’re living it right now.

After our Backstage investment failed to deliver ROI, we did a full reset. Here’s what we learned:

What we tried to build:

Service catalog
Documentation portal
Deployment dashboard
Cost visibility
Security compliance tracking

What was actually unique to our company:

Integration with our proprietary deployment system (built 2015, predates modern CI/CD)
Custom compliance reporting for our regulated industry

Everything else: Standard problems with existing solutions.

The New Platform Team

We restructured our platform team based on this realization:

Old team (12 people):

8 backend engineers
2 frontend engineers
1 DevOps engineer
1 security engineer

New team (5 people):

1 product manager (new role)
1 UX designer (new role)
2 integration engineers (repurposed from backend)
1 vendor/tooling specialist (new role)

We cut headcount by 58% and we’re delivering MORE value.

The Integration Model

Here’s what the new team actually does:

Adopted managed solutions:

Service catalog: Port ($180K/year)
Documentation: ReadMe ($60K/year)
Observability: Datadog (already had, $200K/year)
FinOps: Kubecost ($40K/year)

Built custom integrations:

Port ↔ proprietary deployment system
Compliance data → Port
Cost data → unified dashboard

Total spend:

Managed tools: $480K/year
Team cost: $750K/year (down from $1.8M)
Total: $1.23M/year (down from $3M initial + $620K/year)

The Results

6 months into new model:

Adoption: 68% (up from 31%)
Time-to-value: 3 months (vs 18 months)
Developer satisfaction: 7.8/10 (vs 4.2/10)

Measurable impact:

Onboarding time: 5 days → 2 days
“Who owns this?” questions: Down 73%
Deployment confidence: Up 41%
Incident MTTR: Down 22%

The integration model works.

The Skills Shift

Your point about hiring is critical. We had to let go of some engineers and hire different skills.

What we needed then: Deep systems knowledge, could build anything from scratch

What we need now:

Product thinking (understand user needs)
API integration expertise (connect things)
Vendor evaluation skills (build vs buy decisions)
Change management (drive adoption)

One of our best backend engineers quit because “I didn’t sign up to be a product manager.” That hurt, but it was the right outcome. We needed different skills.

The FinOps Integration

Your FinOps point is spot-on. This is eating up more platform team time than expected.

We’re pulling cost data from:

AWS Cost Explorer
Datadog
Snowflake
GitHub Actions
Various SaaS tools

The ask from leadership: “Show me cost per service, per team, per feature.”

Nobody sells that out of the box. It requires:

Data pipeline from 8+ sources
Normalization and attribution logic
Dashboard with drill-down capabilities

This is genuinely custom work. But it’s integration work, not building a cost platform from scratch.

The AI Chaos

And AI is making everything more complex. We’ve got:

Engineers using Cursor/Copilot (cost: varies)
DataDog AI (included in subscription)
Snyk AI security scanning ($40K/year)
Various teams experimenting with Claude, GPT-4

Platform team is now responsible for:

Evaluating which AI tools to standardize on
Measuring productivity impact
Managing costs (tokens add up fast)
Security review (what’s being sent to AI providers)

This is a NEW platform responsibility that didn’t exist 2 years ago.

What’s Genuinely Unique

Your question about what’s truly unique is the key insight.

For us, it’s:

Proprietary deployment system integration (legacy, can’t replace)
Industry-specific compliance reporting (healthcare regs)

That’s it. Everything else has a vendor solution.

If we’d started with that realization, we would have:

Bought managed solutions for 90% of needs
Built custom integrations for our 10% unique needs
Saved $2M and 12 months

The 2027 Prediction

I agree with all your predictions, but I’ll add one more:

By 2027, “platform engineer” will split into two distinct roles:

Platform Product Manager: Evaluates tools, designs experience, drives adoption
Platform Integration Engineer: Builds connectors, maintains integrations, solves technical glue problems

The full-stack “build the whole platform” engineer becomes rare, limited to companies with genuinely unique needs at massive scale.

My Advice to Others

If you’re building a platform team in 2026:

Start with managed solutions - Default to buy, build only if you must
Hire for integration skills - Not full-stack platform builders
Add product/design - This is a product problem, not just a tech problem
Measure adoption - Not features shipped
Plan for AI integration - It’s coming faster than you think

The DIY era is dead. Those of us who learned that the expensive way can save you the pain.

eng_director_luis · March 22, 2026, 4:36am

Keisha, Michelle—reading this thread feels like watching the industry catch up to what we learned the hard way.

The Shift I’m Seeing

I manage platform teams at 3 companies (current + 2 consulting engagements). Here’s what I’m observing:

Company A (180 engineers): Still trying to build everything. Bleeding money and morale.

Company B (250 engineers): Switched to integration model 8 months ago. Thriving.

Company C (400 engineers): Hybrid approach. Struggling to justify the build portions.

The pattern is clear: Integration model wins.

The Hard Conversation

But here’s the organizational challenge: How do you tell a team of platform engineers “we’re not building anymore, we’re integrating”?

I had this conversation last month. Here’s what happened:

My message: “We’re shifting from building to integrating. We’ll adopt managed solutions for most needs and build only what’s unique.”

Team reaction:

3 engineers: “Finally, this makes sense”
4 engineers: “So we’re just becoming vendor managers?”
2 engineers: “I didn’t become an engineer to wire together SaaS tools”
1 engineer: Quit within 2 weeks

The identity crisis is real.

Redefining “Platform Engineer”

Michelle’s prediction about role splits is already happening. Here’s what I’m seeing:

Traditional Platform Engineer (dying):

Builds everything from scratch
Full-stack capabilities
Systems architecture focus
“Not invented here” syndrome

Modern Platform Engineer (emerging):

Integration-first mindset
API expertise over full-stack
Product thinking over pure tech
Pragmatic build-vs-buy evaluation

The second type is harder to find. They exist at the intersection of engineering and product, which is rare.

The Skills I’m Hiring For

When I post “Platform Engineer” roles now, I’m looking for:

Required:

API integration experience
Product thinking
User research skills (yes, really)
Vendor evaluation capability
Change management experience

Nice to have:

Full-stack development
Systems architecture

Notice the flip? Full-stack is now “nice to have,” not required.

The Integration Complexity

Here’s what people underestimate: Integration is legitimately hard.

It’s not “just wire some APIs together.” It’s:

Technical challenges:

Inconsistent data models across vendors
Authentication complexity (OAuth, SAML, API keys, etc.)
Rate limiting and reliability issues
Real-time vs batch sync decisions
Data consistency and conflict resolution

Product challenges:

Designing unified UX across disparate tools
Managing user expectations across vendor limitations
Deciding what to surface vs hide
Handling vendor feature changes

Organizational challenges:

Negotiating contracts
Managing vendor relationships
Handling vendor outages
Planning for vendor changes/sunset

This is real engineering work. Just different than building from scratch.

The FinOps Reality

Keisha mentioned FinOps integration. This is consuming 40% of my platform team’s time right now.

The requirement: Engineers need to see “What does my service cost?” before merging PRs.

What that actually requires:

Pull compute costs (AWS, GCP)
Pull storage costs
Pull data transfer costs
Pull observability costs (Datadog, Sentry)
Pull CI/CD costs (GitHub Actions)
Pull AI costs (OpenAI API)
Attribute all costs to services
Show trend over time
Predict cost impact of changes

No vendor does this end-to-end. We’re building integration layer to make it happen.

This is the future of platform engineering: Complex integration work that delivers real business value.

The AI Integration Mess

And AI is making everything 10x more complex.

Current state:

40% of engineers use Cursor
30% use GitHub Copilot
20% use both
10% use neither

Questions we’re fielding:

Which should we standardize on?
How do we measure productivity impact?
What’s being sent to AI providers? (security concern)
How do we manage costs?
Should we self-host models?

Platform team is now responsible for “AI strategy for engineering.” Nobody planned for this.

The Build Justification Bar

Here’s my new framework for build-vs-buy:

Build if ALL of these are true:

No vendor solution exists for this specific need
The problem is genuinely unique to our domain
The value is >$500K/year
We have capacity to maintain it for 3+ years
We can ship MVP in <3 months

If ANY answer is “no,” we buy.

With this framework, we build about 10% of our platform. We integrate the other 90%.

The Vendor Ecosystem

Michelle’s spending $480K/year on managed tools. Here’s our breakdown for 250 engineers:

Service catalog: Port ($200K/year)
Docs platform: GitBook ($80K/year)
Observability: Datadog ($300K/year - existing)
FinOps: Vantage ($60K/year)
Security scanning: Snyk ($100K/year - existing)
CI/CD: GitHub ($50K/year - existing)

Total: $790K/year for tools

Platform team: 4 people = $600K/year

Total platform cost: $1.39M/year

Compare to building everything: Would cost $2M+ first year, $800K+ ongoing, and take 12 months to launch.

We’re saving money AND shipping faster.

What’s Genuinely Unique

Your question about what’s truly unique is the right one.

For most companies, the answer is:

Integration with legacy systems (nobody else has your exact legacy)
Industry-specific compliance (healthcare, finance, etc.)
Domain-specific workflows (if you’re in a rare industry)

That’s it. Service catalogs, documentation, observability, deployment—these are solved problems with vendor solutions.

The 2027 Landscape

I’ll make a bolder prediction than Keisha:

By 2027:

95% of platforms will be primarily integrated, not built
Average platform team size: 3-4 people (down from 8-12)
Build-from-scratch limited to <5% of companies
“Platform engineer” will mean “integration engineer”
Self-hosted Backstage will be niche, not default

We’re watching an industry mature from “build everything” to “integrate everything.”

The companies that adapt win. The ones that cling to DIY ideology lose.

product_david · March 22, 2026, 4:38am

Keisha, this thread is the clearest articulation I’ve seen of where platform engineering is headed.

As a PM who’s worked on both product platforms and internal platforms, I want to add the product lens to this discussion.

The Platform-as-Product Realization

Here’s the fundamental insight that changed my thinking:

Internal platforms are products. They need product management, not just engineering.

But most companies treat platforms as infrastructure projects:

Engineering-led, no PM
Feature-focused, not outcome-focused
Build-centric, not user-centric

This is why adoption fails.

The Product Thinking Gap

I’ve done user research with 50+ engineers across 5 companies on why they don’t use internal platforms.

What platform teams think is the problem:

“We need more features”
“We need better documentation”
“We need to educate users”

What users actually say:

“I tried it once, it didn’t solve my immediate problem”
“It’s easier to ask in Slack than learn a new tool”
“The UI is confusing”
“It’s slower than my current workflow”

These are PRODUCT problems, not TECHNOLOGY problems.

The Integration Mindset

Keisha’s shift from building to integrating is fundamentally a product decision:

Build mindset: “What features should a platform have?”
Integration mindset: “What’s the best existing solution for each user need?”

The second question leads to different answers:

User need: “Find service ownership”
Build answer: “Build service catalog from scratch”
Integration answer: “Integrate GitHub CODEOWNERS, PagerDuty schedules, and Slack channels into unified view”

Integration is faster, cheaper, and often better UX because vendors have dedicated designers.

The Vendor Evaluation Framework

When evaluating managed solutions, I use this framework:

Must-haves:

Solves user problem better than DIY
Adoption rate >60% at reference customers
Integration capabilities with our stack
Pricing scales reasonably with growth

Nice-to-haves:

Customization options
API for extending
Good vendor support
Product roadmap alignment

With this framework, we’ve adopted:

Port for service catalog
Linear for issue tracking
Notion for documentation
Datadog for observability

Each was “buy” not “build” because they met all must-haves.

The Adoption Playbook

Michelle’s jump from 31% to 68% adoption is the key metric. Here’s how you drive that:

1. Start with one high-value use case

Not comprehensive solution
One workflow that saves meaningful time
Example: “Find who’s on-call for this service”

2. Measure time saved

Before: 5 minutes to find on-call via Slack
After: 10 seconds via platform
Savings: 4:50 per lookup
At 200 lookups/week: 16 hours saved

3. Show the value

Dashboard showing time saved
Slack announcements of wins
Engineering all-hands demos

4. Expand from adoption

Once feature #1 hits 60% adoption, add feature #2
Build on success, don’t launch everything at once

This is basic product management. But platform teams rarely do it.

The FinOps Opportunity

Luis mentioned FinOps consuming 40% of platform team time. I see this as the BIGGEST opportunity for platform teams in 2026.

Why? Because cost visibility directly impacts business outcomes.

Traditional platform work:

“We made deployments 2 minutes faster”
Hard to quantify business value

FinOps platform work:

“We identified $400K in unused resources”
“We reduced data transfer costs by $80K/year”
Direct P&L impact

This is how platform teams justify their existence. Show cost savings > platform team cost.

The AI Integration Product Problem

Every company is facing this: Engineers are adopting AI tools in a chaotic, unmanaged way.

The platform team opportunity:

Evaluate AI coding tools (Cursor, Copilot, others)
Measure productivity impact
Standardize on best tool
Negotiate volume pricing
Manage security/privacy concerns

This is a product problem:

What do users need?
What tools solve those needs?
How do we drive adoption?
How do we measure success?

It’s not “build an AI tool.” It’s “integrate AI into developer workflow.”

The Metrics That Matter

Platform teams need to adopt product metrics:

Stop measuring:

Features shipped
Services onboarded
API coverage

Start measuring:

Daily active users
Time saved per user
User satisfaction (NPS)
Adoption rate
Time-to-productivity for new hires

These are product metrics. They correlate with business value.

The Build vs Integrate Decision

Here’s my controversial take:

99% of companies should build <10% of their platform.

The only things worth building:

Integration glue between tools
Genuinely unique domain logic
Custom workflows that span multiple tools

Everything else: Buy or integrate existing tools.

Why? Because vendors have:

Product managers
Designers
Customer success teams
Dedicated engineering teams
Multi-customer feedback loops

You can’t compete with that for standard features.

The Platform Team Structure

Michelle’s new team structure is the future:

Essential roles:

Product Manager (designs experience, prioritizes, measures outcomes)
UX Designer (makes it usable)
Integration Engineer (builds connectors)
Vendor Manager (evaluates, negotiates, manages relationships)

Not needed:

Full-stack engineers (for building from scratch)
DevOps engineers (vendors handle ops)
Security engineers (vendors handle security)

The team shrinks from 12 to 4-5, but delivers more value.

The 2027 Prediction

I’ll add to Keisha’s predictions:

By 2027:

Every platform team has a dedicated PM (not optional)
UX design is standard, not nice-to-have
“Platform engineer” job descriptions require product thinking
Self-service vendor ecosystems dominate
Build-from-scratch is considered legacy approach

The platform engineering role is evolving from “infrastructure builder” to “experience curator.”

The companies that adapt to this will have platforms people actually use. The ones that don’t will keep building unused tools.

My Final Point

If your platform has <50% adoption, you don’t have a technology problem. You have a product problem.

No amount of engineering will fix it. You need product thinking, user research, and focus on outcomes over features.

The DIY era is dead because it optimized for building, not for users.

The integration era optimizes for users. And that’s what actually drives value.

maya_builds · March 22, 2026, 4:38am

Keisha, you’ve described the future. Let me add what it feels like from the design perspective, because this shift changes everything about how we think about platform UX.

The Design Paradigm Shift

Old platform design challenge: “How do we design a comprehensive platform?”

New platform design challenge: “How do we create cohesive experience from disparate tools?”

These require completely different skills.

The Integration UX Problem

When you’re integrating 5+ tools, the UX challenge isn’t “design a feature.” It’s:

1. Consistency across inconsistent sources

Example: Service ownership data comes from:

GitHub CODEOWNERS
PagerDuty schedules
Slack channels
JIRA projects

Each has different data models, different update frequencies, different reliability.

Design question: How do you surface “who owns this service” when the answer varies by source?

Answer: Design for data ambiguity, not perfect data.

Show multiple sources
Indicate freshness
Allow user to resolve conflicts

This is NEW design territory. Consumer products assume consistent data. Platform integration doesn’t have that luxury.

2. Cross-tool workflows

Example: Deploy a service

Check status: Datadog
Review changes: GitHub
Trigger deploy: Spinnaker
Verify deploy: Datadog
Update docs: Confluence

Old approach: Build unified deploy UI that does all this
New approach: Design workflow that moves user across tools seamlessly

This means:

Deep linking to exact context in each tool
Consistent visual language across tools
Clear workflow progression
Minimal context switching

3. Vendor UI constraints

When you’re integrating vendor tools, you’re stuck with their UI decisions.

Example: Port has one navigation model, Datadog has another.

Design challenge: Create unified entry point that works with both.

Solution: Meta-layer design

Platform is the router, not the destination
Clear handoffs to vendor tools
Bring context back from vendors into platform

The Designer’s Role Evolution

Michelle’s new team has 1 UX designer. Here’s what that designer actually does:

Not:

Design comprehensive platform UI
Create design system from scratch
Build prototypes for custom features

Instead:

Design integration layer between tools
Create consistent navigation across vendors
Design handoff experiences
Optimize for workflow efficiency across tools

The skill set is different. It’s more about service design than product design.

The FinOps UX Challenge

Luis mentioned FinOps taking 40% of time. The UX challenge here is massive:

The ask: Show “what does my service cost”

The reality: Data from 8+ sources with different:

Update frequencies (real-time to daily)
Granularity (account-level to resource-level)
Attribution models (tags, labels, naming conventions)
Accuracy (estimates vs actuals)

Design challenge: How do you show cost data when it’s messy, delayed, and inconsistent?

Bad UX: Show all raw data, let users figure it out
Good UX:

Show high-confidence data prominently
Indicate uncertainty and freshness
Provide drill-down for details
Explain discrepancies

This requires design thinking about data quality, not just visual design.

The AI UX Wild West

The AI integration challenge is even more complex from UX perspective:

Engineers are using:

Cursor for inline suggestions
ChatGPT for architecture discussions
GitHub Copilot for code completion
Claude for code review

Platform team question: “Should we standardize?”

Design question: “How do we design for AI-assisted workflows?”

This is brand new territory. Nobody has patterns for:

When to suggest AI assistance
How to show AI-generated code alongside human code
How to build trust in AI suggestions
How to measure AI impact on developer experience

The Adoption Design Pattern

Michelle jumped from 31% to 68% adoption. The design factors that drive this:

1. Immediate value on first use

No onboarding required
No “learn the system” period
Solves problem in <30 seconds

2. Faster than alternatives

Platform: 10 seconds
Slack: 5 minutes
Speed drives adoption

3. Works where developers work

Slack integration
CLI tools
IDE plugins
Not just web UI

4. Progressive disclosure

Show simple view by default
Advanced features available but hidden
Don’t overwhelm on first use

These are UX principles that platform teams often ignore.

The Multi-Tool Experience

Here’s a concrete example of integration UX:

User journey: “Deploy my service”

Touch points:

Platform: Check deployment readiness
GitHub: Review PR
Platform: Trigger deploy
Slack: Get deployment notification
Datadog: Verify health
Platform: Mark deployment complete

Design challenge: Make this feel like ONE workflow, not 6 disconnected steps.

Solution:

Deep links with context
Status tracking across tools
Unified notification system
Single source of truth for deployment state

This is integration UX design. It’s not designing features—it’s designing across features.

The Vendor Relationship

When you adopt managed tools, you’re dependent on their design decisions.

Example: We use Port for service catalog. Their UI is good but not perfect for our workflow.

Options:

Request feature changes (slow, might not happen)
Build wrapper UI (expensive, maintenance burden)
Adapt our workflow to their UI (fastest, often best choice)

Design wisdom: Pick battles. Don’t fight vendor UI unless it’s critically broken.

The 2027 Platform UX

Keisha’s predictions are right. Here’s what platform UX looks like:

Not:

Comprehensive platform UI
Custom-designed every screen
Proprietary design system

Instead:

Lightweight integration layer
Vendor UIs for deep work
Consistent navigation and context

The designer’s job:

Design integration layer
Optimize cross-tool workflows
Manage vendor UI relationships
Measure and improve user experience

My Controversial Take

Most platform teams don’t need a full-time designer.

They need:

0.5 FTE UX designer (design integration layer, workflows)
0.5 FTE user researcher (understand pain points, measure adoption)

Why? Because vendor tools already have designers. You’re not designing everything—you’re designing the thin layer that connects everything.

The Skills Gap

The platform designers I’m hiring for have different skills than product designers:

Required:

Service design thinking
Multi-tool workflow expertise
Data visualization skills (for FinOps, observability)
User research capability

Nice to have:

Visual design skills
Prototyping tools
Design systems

Notice the flip? Visual design is now “nice to have.”

The Bottom Line

Keisha asked: “Is platform team’s job building tools or enabling ecosystem?”

From design perspective: Definitely enabling ecosystem.

Our job isn’t to design comprehensive platforms. It’s to design the connective tissue that makes disparate tools feel cohesive.

That’s a different design problem than we’ve ever solved before. And it’s the future of platform UX.