Built a Custom Platform in 2024—Now Everyone's Buying Solutions. Did We Make a Mistake?

system · March 17, 2026, 11:29am

I’m having a bit of an existential crisis and need some real talk from this community.

The Context

Two years ago (early 2024), I was the founding platform engineer at a Series B startup. We had 60 engineers, growing fast, and complete infrastructure chaos. Teams were managing their own Kubernetes clusters, writing custom deployment scripts, and our time-to-production for new services was 2-3 weeks.

Leadership gave me a mandate: “Fix this. We need a platform.”

I looked at the market:

Heroku: Too expensive at scale, limited flexibility
Platform.sh: Didn’t support our tech stack
Early Backstage: Still immature, required massive customization anyway
Cloud-native PaaS offerings: Either too basic or too enterprise (AWS Proton was laughably early)

So we did what any self-respecting engineer would do: we built our own.

What We Built (2024-2025)

Custom IDP (Internal Developer Portal) on React + FastAPI
Terraform module library (50+ modules covering our entire stack)
CLI tool for service scaffolding and deployment
GitOps pipeline with ArgoCD
Service catalog with automated dependency tracking
Cost attribution engine
Integration with our existing GitHub/Slack/PagerDuty workflow

Team size: 3 platform engineers (including me)
Development time: 8 months to MVP, another 6 months to production-ready
Cost: ~$1.2M in loaded headcount + infrastructure

It worked. Like, really worked:

Time-to-production: 2-3 weeks → 4 hours
Platform adoption: 89% of teams
NPS: 72
Saved estimated $400K/year in cloud waste
Enabled us to scale from 60 → 180 engineers without infrastructure chaos

We were heroes. I was promoted. The CTO presented our platform at conferences.

The 2026 Problem

Fast forward to today. The market has completely matured:

Backstage is production-ready with a massive plugin ecosystem
Port, Humanitec, Cortex have become legitimate enterprise platforms
AWS Proton actually works now
Vercel, Netlify, Railway handle 80% of use cases out of the box
Every cloud provider has a PaaS offering that doesn’t suck

Our new VP of Engineering (hired 3 months ago) just came from a company using Humanitec. In her 1:1 with me last week:

Her: “Why are we maintaining a custom platform when we could just buy Humanitec for $200K/year?”
Me: “Because our platform is tailored to our exact needs.”
Her: “Is it worth $1M/year in team cost to maintain?”
Me: “…”

The Sunk Cost Dilemma

Here’s where I’m stuck:

Arguments for keeping our custom platform:

We own the entire stack, no vendor lock-in
Perfect integration with our specific workflow
Features we need that commercial platforms don’t have (yet)
Team knows it intimately, no onboarding to new tools
Pride (not a business reason, but it’s real)

Arguments for switching to a commercial platform:

Platform team could focus on differentiated problems instead of maintenance
Commercial platforms have dedicated teams working on features we’ll never build
Lower operational overhead (someone else handles upgrades, security, compliance)
Faster time-to-new-features (plugin ecosystem vs building everything ourselves)
Easier hiring (people know Backstage, nobody knows our custom portal)

The emotional reality:
I poured two years of my life into this platform. It’s my baby. The idea of ripping it out and replacing it with a commercial product feels like admitting failure.

But intellectually, I know the market has moved. In 2024, building custom made sense. In 2026, does it still?

The Questions Keeping Me Up at Night

Is custom platform engineering still a defensible strategy in 2026? Or has the market matured to the point where “buy” beats “build” for 90% of companies?
How do you evaluate the TCO honestly? Our platform “costs” $1M/year in headcount, but those engineers would be doing something else. Is that really a fair comparison?
What’s the switching cost? Migrating 180 engineers and 200+ services to a new platform would be massive. Is the disruption worth it?
Are we solving problems that actually matter? Or are we maintaining custom solutions out of habit/pride?
What happens to the platform team? If we buy instead of build, what do three platform engineers do? (This is not a small question for morale.)

What I’m Actually Asking

I need reality checks from people who’ve been through this:

Have you migrated from custom platforms to commercial solutions? How did it go?
Are you still maintaining custom platforms in 2026? Is it still worth it?
How do you make this decision without ego getting in the way?
What signals told you it was time to switch?

The pragmatic part of me knows the right answer is probably “evaluate objectively, check ego at the door, do what’s best for the company.” But the engineer in me who built this thing from scratch is having trouble letting go.

Help me think through this. Did we make a mistake building custom in 2024? Or are we making a mistake keeping it in 2026?

eng_director_luis · March 17, 2026, 11:34am

Maya, first: you didn’t make a mistake in 2024. Given the market maturity then, building custom was probably the right call. The question is whether it’s still the right call in 2026.

I’ve been on both sides of this—built custom platforms, migrated to commercial solutions, and even migrated back to custom in one case. Here’s my framework:

DIY Platforms Aren’t Dead (But the Bar Is Higher)

Custom platforms still make sense when:

1. Your Domain is Genuinely Unique
Not “we have special needs” (everyone thinks that). I mean truly differentiated requirements:

Heavily regulated industry with compliance requirements no vendor supports
Extreme scale (millions of deploys/day) where commercial platforms break down
Novel tech stack that commercial platforms don’t support (quantum computing, edge-native, etc.)

2. Platform Engineering IS Your Competitive Advantage
Some companies (Vercel, Shopify, Netflix) compete on developer experience. For them, custom platforms are strategic investments, not cost centers.

If you’re not in this category, custom probably doesn’t make sense anymore.

3. You’ve Got Surplus Platform Engineering Capacity
If your team is 10+ platform engineers and they’re bored, building custom might be fine. If you’re 3 people barely keeping the lights on, buy.

Your Specific Situation

From what you described:

Company size: 180 engineers (not large enough to justify custom IMO)
Platform team: 3 people (too small to maintain custom long-term)
Industry: Not mentioned, but probably not regulated enough to require custom
Adoption & NPS: Excellent, which actually makes migration easier (users trust the platform team)

Verdict: You should probably migrate to a commercial platform.

The TCO Analysis (Honest Version)

Your VP is right to question the $1M/year cost, but here’s the full picture:

Custom Platform TCO:

$1M/year headcount (3 engineers)
Infrastructure costs (probably $50-100K/year)
Opportunity cost (what else could those 3 engineers build?)
Technical debt accumulation (maintenance burden grows over time)
Total: ~$1.2M/year + opportunity cost

Commercial Platform TCO:

$200K/year license (probably more like $300-400K for 180 engineers, but let’s use their number)
0.5 FTE to manage vendor relationship, customization ($100K)
Migration cost (one-time, probably 6-12 months, $300K)
Reduced flexibility (hard to quantify)
Total: ~$300K/year + one-time migration

Break-even: 6-12 months after migration.

After that, you’re saving $700K+/year. That’s a real CFO argument.

What Happens to the Platform Team?

This is the real question, and it’s why ego gets in the way.

Option 1: Dissolve the Team (Bad)
Don’t do this. You’ll lose institutional knowledge and demoralize everyone.

Option 2: Pivot to Higher-Level Problems (Good)
With commercial platforms handling the basics, platform engineers can focus on:

Advanced workflow automation
Custom integrations the vendor doesn’t provide
Developer experience optimization
Platform adoption and evangelism
Cost optimization and FinOps

Option 3: Hybrid Model (Best)
Use commercial platform as the foundation, build custom layers on top for truly differentiated needs. This is what I’ve seen work best.

The Migration Reality Check

You asked about switching costs. Here’s what a realistic migration looks like:

Phase 1: Pilot (2 months)

Migrate 1-2 friendly teams to commercial platform
Identify gaps and integration challenges
Build confidence that this will work

Phase 2: Gradual Migration (6-9 months)

Migrate teams in waves (10-20 teams/month)
Keep custom platform running in parallel
Build migration tooling and runbooks

Phase 3: Deprecation (3 months)

Migrate holdout teams
Sunset custom platform infrastructure
Archive code with dignity

Total: 12-18 months. It’s not fast, but it’s not as disruptive as a rip-and-replace.

The Ego Question

You said pride isn’t a business reason, but you’re wrong—it’s a human reason, and those matter.

You built something great. It works. Users love it. That’s a real accomplishment, and migrating away doesn’t erase that.

Reframe it: You’re not admitting failure. You’re recognizing that the market caught up to your vision. You were early. Now you can leverage the industry momentum instead of fighting it.

My Recommendation

Do a formal build-vs-buy analysis with your VP. Use real numbers, include opportunity cost.
Run a pilot with Backstage or Humanitec (whichever fits your stack). 6-week eval with 2 teams.
Decide based on data, not emotion.

If the pilot shows commercial platforms can handle 80% of your needs, migrate. Use your saved capacity to build the 20% that actually differentiates your company.

You didn’t make a mistake in 2024. Don’t make the mistake of not adapting in 2026.

(Also: your VP asking this question 3 months in is either really smart or really threatening. Make sure you’re driving the analysis, not having it imposed on you.)

cto_michelle · March 17, 2026, 11:35am

Maya, Luis covered the tactical analysis brilliantly. I want to address the strategic and organizational dynamics because I’ve been the VP making this decision.

The Build vs Buy Framework (Executive Perspective)

When I evaluate platform investments, I use this hierarchy:

Tier 1: Core to Business Model

Build. No question.

Shopify’s internal deployment platform: Core to their ability to serve merchants
Netflix’s chaos engineering platform: Core to their reliability promise
Your platform: Probably not Tier 1 (unless developer experience is your competitive moat)

Tier 2: Significant Differentiator

Build with caution. Requires ongoing justification.

Unique compliance/regulatory requirements
Novel tech stack with no commercial support
Scale that breaks commercial platforms (millions of deploys/day)

Tier 3: Necessary Infrastructure

Buy or adopt open source. Don’t build from scratch.

CI/CD pipelines (use GitHub Actions, GitLab CI, etc.)
Observability (use Datadog, New Relic, etc.)
Developer portals (use Backstage, Port, etc.)

Most companies think their platform is Tier 1 or 2. Most are actually Tier 3.

The 2024 → 2026 Shift

You made the right call in 2024 because commercial platforms weren’t ready. But the market has shifted:

What changed:

Backstage hit production maturity (~2024-2025)
Enterprise platforms (Humanitec, Port, Cortex) got serious traction
Plugin ecosystems exploded (Backstage has 200+ plugins now)
Integration gaps closed (most platforms integrate with everything)

What this means:
Building custom in 2026 is no longer “early adopter smart”—it’s “ignoring market reality.”

The Hidden Costs You’re Not Counting

Your $1M/year TCO calculation is missing:

1. Maintenance Burden (Grows Exponentially)

Security patches and dependency updates
Breaking changes in underlying infrastructure
Feature requests from 180 engineers
Documentation that becomes stale
Onboarding new platform team members

In year 1, maintenance is 20% of the team’s time. By year 3, it’s 60%+. You’re about to hit that wall.

2. Opportunity Cost (The Big One)
What could your 3 platform engineers build if they weren’t maintaining plumbing?

Advanced FinOps automation (cloud spend optimization)
Developer experience improvements (custom workflows, integrations)
Platform evangelism and adoption (internal product management)
Emerging tech evaluation (AI-assisted development, new toolchains)

These are high-leverage activities that commercial platforms free you up to do.

3. Talent Risk

Hiring is harder (custom platforms require ramp-up time)
Retention is harder (engineers want résumé-building skills like Backstage, not YourCo Internal Portal v2)
Burnout risk is higher (maintaining legacy systems is soul-crushing)

4. Innovation Drag
Commercial platforms ship new features constantly:

Backstage adds 10-15 plugins/month
Humanitec shipped score cards, cost tracking, and compliance automation in the last 6 months
You ship… what you have capacity for (which is declining)

The Organizational Dynamics (The Real Issue)

Your VP is new. She came from a company using Humanitec. She’s questioning the custom platform.

Here’s what’s actually happening:

She thinks the custom platform is technical debt
She’s probably right
Your defensive response is confirming her suspicion
If you don’t own the transition, she’ll impose it

What You Should Do (Tactically)

Week 1: Change Your Framing
Stop defending the custom platform. Start positioning yourself as the person who can navigate the transition.

Message to your VP:
“You’re right to question whether custom still makes sense. The market has matured significantly. I’d like to lead an evaluation of commercial platforms with a 60-day pilot. If we can migrate without losing the capabilities our users depend on, we should.”

Week 2-3: Build the Analysis

Map your custom platform features to commercial platform capabilities (gap analysis)
Calculate real TCO (include opportunity cost)
Interview 10-15 users about what they actually need vs what exists
Build migration cost estimate

Week 4-12: Run Pilot

Pick Backstage (open source, lower risk) or Humanitec (managed, faster)
Migrate 2-3 friendly teams
Document gaps, integration challenges, and workarounds

Week 13: Present Decision
“Based on our pilot, we can migrate 85% of functionality to [Platform]. The remaining 15% we can build as plugins. Migration will take 12 months and cost $400K. We’ll save $700K/year ongoing and free up the platform team for higher-value work.”

The Outcome Scenarios

Scenario 1: Commercial Platform Works (80% probability)
You migrate, users adapt, platform team pivots to higher-level problems, everyone is fine in 18 months.

Scenario 2: Commercial Platform Has Gaps (15% probability)
You adopt hybrid model: commercial platform as foundation, custom plugins for differentiated needs. This is actually the best outcome—you get vendor momentum + custom value-add.

Scenario 3: Commercial Platform Fails (5% probability)
You discover genuine gaps that can’t be solved with plugins. You keep custom platform, but now you have data to justify it to leadership. Your VP respects that you evaluated honestly.

The Bottom Line

You didn’t make a mistake in 2024. But markets evolve. The custom platform that was strategic in 2024 is technical debt in 2026.

Own the transition. Don’t have it done to you.

Lead the evaluation, drive the decision, and position yourself as the person who can navigate complex migrations. That’s way more valuable than being the person who built a thing once.

Your career ceiling is higher if you’re the leader who makes pragmatic decisions than if you’re the engineer who defends legacy systems.

(And hey—imagine putting “Migrated 180-engineer org from custom platform to Backstage in 12 months” on your résumé. That’s a hell of a lot more impressive than “Maintained internal platform for 4 years.”)

vp_eng_keisha · March 17, 2026, 11:36am

Michelle and Luis nailed the technical and strategic analysis. I want to talk about the change management side because that’s where most platform migrations fail.

The Human Side of Platform Migration

You have 180 engineers who are happily using a platform with 89% adoption and 72 NPS. That’s incredible. Most platform teams would kill for those numbers.

Now you’re going to tell them “hey, that thing that works great? We’re replacing it.”

This is where things go sideways.

The Change Management Failure Modes

I’ve seen three ways this goes wrong:

Failure Mode 1: The Surprise Replacement
Leadership decides to migrate, announces it in all-hands, engineering is blindsided.

Result: Passive resistance, shadow IT, platform team viewed as traitors

Failure Mode 2: The Forced March
Hard cutover date, no gradual migration, teams scramble to adapt.

Result: Productivity crater, bugs, outages, platform team blamed for chaos

Failure Mode 3: The Eternal Pilot
Pilot runs for 6 months, no decision made, teams stuck in limbo.

Result: Paralysis, loss of trust in platform team decision-making

The Right Way to Migrate (Change Management Lens)

Phase 0: Build the Coalition (Before Announcing Anything)

Talk to your power users—the engineering leads who are platform champions:

“The market for platform tooling has matured significantly. We’re evaluating whether custom still makes sense vs adopting Backstage/Humanitec. What capabilities do you absolutely need? What could we change?”

Get 5-10 allies who understand the rationale before you go wide. They’ll be your evangelists during the transition.

Phase 1: Transparent Communication

Don’t hide the evaluation. Be radically transparent:

All-hands announcement: “We built an amazing platform in 2024, but the market has changed. We’re evaluating commercial platforms to see if they can meet our needs while freeing up the team for higher-level work.”
Weekly updates during evaluation (even if it’s just “we’re still testing”)
Public decision criteria so the process doesn’t feel like a black box

Phase 2: User-Centric Migration

Involve users in the process:

Pilot with volunteers (don’t voluntold)
Create a migration feedback channel (Slack, office hours)
Celebrate teams that migrate successfully
Don’t shame teams that struggle

Phase 3: Support Intensity

Triple your support capacity during migration:

Office hours 3x/week
Migration runbooks for every use case
Dedicated Slack channel with <15min response SLA
Pairing sessions for complex migrations

This is where most teams under-invest and then wonder why the migration “failed.”

The Messaging Framework

How you frame this matters enormously:

Bad Framing:
“The custom platform was a mistake. We’re switching to Backstage.”

Implies: We wasted 2 years and $1.2M
Reaction: Anger, loss of confidence in platform team

Good Framing:
“We built exactly what we needed in 2024 when commercial platforms weren’t ready. Now the market has caught up, and we can leverage industry momentum instead of maintaining everything ourselves. This frees us up to build the 20% that actually differentiates us.”

Implies: We made smart decisions then and now
Reaction: Trust that platform team is adapting to reality

The Platform Team Morale Problem

You mentioned: “What happens to the platform team if we buy instead of build?”

This is real. I’ve seen platform engineers quit during these transitions because they feel like their work is being thrown away.

How to retain your team:

1. Reframe Their Work
“You built the blueprint. Now the industry has adopted it. You were ahead of the curve.”

2. Give Them Ownership of the Transition
Make them the migration experts:

They know the old platform intimately
They’re best positioned to map features to new platform
They can build custom plugins for gaps
They become internal experts on the new platform

3. Define the Next Chapter
What do platform engineers do after migration?

Developer experience optimization (custom workflows, advanced automation)
Platform evangelism and adoption (internal product management)
Strategic tooling evaluation (AI-assisted development, emerging tech)
Cost optimization and FinOps

These are higher-leverage problems than maintaining plumbing.

The Timeline Reality

Michelle said 12-18 months. That’s right, but here’s the week-by-week breakdown:

Months 1-2: Evaluation & Pilot

Build vs buy analysis
Pilot with 2-3 teams
Gap analysis and decision

Months 3-4: Foundation

Procurement and contracting (if buying)
Set up production instance
Build migration tooling and runbooks
Train platform team on new platform

Months 5-10: Gradual Migration (The Long Middle)

Migrate teams in waves (2-3 teams/week)
Fix integration issues as they arise
Continuous support and documentation updates
Weekly demos showcasing successful migrations

Months 11-12: Deprecation

Migrate holdout teams
Sunset custom platform infrastructure
Celebrate the transition (seriously, throw a party)

Total: 12 months if you execute well.

The Success Metrics

How do you know if the migration succeeded?

Lagging Indicators (12 months):

Platform NPS stays above 65 (you started at 72, some dip is expected)
Adoption rate stays above 80%
Support ticket volume returns to baseline
Platform team reports higher job satisfaction

Leading Indicators (3-6 months):

Migration velocity (teams/week) stays on track
Support ticket sentiment (frustrated vs neutral vs positive)
Power user feedback (are your champions still champions?)
Platform team morale (weekly pulse checks)

My Take on Your Situation

You built something great. Be proud of that. But also recognize:

The market caught up to your vision
Maintaining custom is increasingly expensive
Your VP is right to question it
You should lead the transition, not resist it

Position yourself as the person who can navigate complex migrations, not the person who defends legacy systems out of pride.

That’s the skill that gets you promoted to Director, VP, and beyond.

(And Maya—seriously, ping me if you want to talk through the change management plan. I’ve done this three times and can share runbooks, communication templates, all of it.)

product_david · March 17, 2026, 11:36am

This entire thread is a masterclass in rational decision-making, but I want to add the product lens because I think you’re missing a critical question:

What job is your platform actually doing for users?

The Product Perspective

You said your platform has:

89% adoption
72 NPS
4-hour time-to-production (down from 2-3 weeks)

Those are phenomenal numbers. But here’s the question: What parts of your platform are users actually valuing?

Because I’ll bet you $100 that:

80% of the value comes from 20% of the features
Most users only use the “happy path” and have never touched advanced features
There are features you maintain that have <5% adoption

This matters for the migration decision.

The Feature Audit You Need to Do

Before you decide to migrate, map your platform capabilities to user value:

Step 1: Usage Analysis

What features are actually being used? (logs, API calls, portal analytics)
What features have <10% adoption?
What features have high adoption but low satisfaction?

Step 2: Value Mapping
Survey your users: “If you could only keep 5 capabilities, what would they be?”

I’ve done this exercise with 4 different internal platforms. Every single time:

3-5 features are “critical, can’t live without”
10-15 features are “nice to have”
20-30 features are “I didn’t know we had that”

Step 3: Gap Analysis
For each critical feature, answer:

Does Backstage/Humanitec support it out of the box? (60% will)
Can it be added via plugin? (30% will)
Would we need to build custom? (10% will)

This tells you if migration is viable.

The Opportunity Cost Lens (Product View)

You said your platform team is 3 people maintaining custom infra. Let’s talk about what they’re NOT doing:

Things a 3-person platform team COULD be doing:

Building workflow automation that saves engineers 2 hours/week each (360 hours/week saved org-wide)
Optimizing cloud costs (probably $200K+/year savings)
Improving onboarding experience (cutting new engineer ramp-up by 1 week)
Building AI-assisted development workflows (copilot for your domain)
Platform evangelism and adoption work (office hours, training, docs)

Things a 3-person platform team IS doing:

Maintaining React + FastAPI codebase
Security patches and dependency updates
Bug fixes and feature requests
Keeping the lights on

Which set of activities has higher ROI?

From a product perspective, maintenance is the lowest-leverage work a platform team can do. You want your best engineers building the future, not maintaining the past.

The Build-Buy-Partner Framework

Here’s how I think about platform decisions in 2026:

Buy (Commercial Platform):

Commodity capabilities (authentication, service catalog, CI/CD orchestration)
Features where vendor can move faster than you
Stuff you need but don’t want to maintain

Build (Custom):

Genuinely differentiated capabilities
Domain-specific workflows
Stuff that’s your competitive advantage

Partner (Integrate):

Best-of-breed tools you can’t beat
Stuff you need but isn’t your core competency
Tools with strong ecosystems

Most platform teams should be 70% buy, 20% partner, 10% build.

You’re currently 100% build. That ratio is unsustainable in 2026.

The Migration Product Roadmap

If you decide to migrate, treat it like a product launch:

Pre-Launch (Months 1-2):

User research (what do people actually need?)
Competitive analysis (what can commercial platforms do?)
Feature parity analysis (what gaps exist?)

Beta (Months 3-4):

Pilot with design partners (2-3 friendly teams)
Rapid iteration based on feedback
Build migration tooling

GA (Months 5-10):

Phased rollout (10% → 25% → 50% → 100%)
Support surge (office hours, pairing sessions, docs)
Success metrics tracking

Post-Launch (Months 11-12):

Deprecate old platform
Retrospective and lessons learned
Define platform team 2.0 roadmap

The Hard Question

Here’s what you need to honestly answer:

Is maintaining your custom platform the highest-leverage thing your team can do?

If yes: Keep it, invest in it, make it great.

If no: Migrate, free up capacity, build differentiated value.

I suspect the answer is no. And that’s not a failure—that’s recognizing that the market has evolved.

The Organizational Risk

One more thing: You said your VP is questioning the platform. That means you’re on borrowed time.

Scenario A: You lead the evaluation

You control the process
You define success criteria
You retain team credibility
If migration makes sense, you own it
If custom still makes sense, you have data to defend it

Scenario B: You resist the evaluation

VP imposes the decision
Migration happens anyway, but messier
You lose credibility as someone who can’t adapt
Your team gets blamed when things go wrong

Choose Scenario A.

Final Thought

You built something great in 2024. The market has caught up. That’s not failure—that’s validation.

Now you have a choice: defend the past or build the future.

I know which one I’d pick.

(And Maya, if you run the feature audit and find that 90% of your custom platform can be replaced with Backstage + 3 plugins, ping me. I’d love to write a case study on this for Platform Engineering Weekly.)