Four deployment pain patterns that keep showing up in public

The Hook

I've been reading every "we left Vercel" / "our cloud bill" / "we're moving to self-hosted" thread I can find.

When deployment pain comes up with engineering leaders in my network, the same themes echo what those threads already say—just with more context.

Four patterns keep repeating. None of them are what platform marketing pages optimize for.

Pattern 1: "I don't know where my code runs"

The sentence that comes up most often in sovereignty and compliance discussions.

Teams often know the region. They still lack clarity on the full chain: machine, sub-processor, or jurisdiction underneath.

For many products that's acceptable. For teams under EU regulatory pressure, healthcare, finance, or government-adjacent workloads, that gap shows up as a recurring blocker in public write-ups and RFP language—not as a niche complaint.

Pattern 2: Bill anxiety beats bill size

In public threads, the complaint is rarely "AWS costs too much in steady state."

It's surprise—traffic spikes, recursive triggers, metered serverless, egress nobody modeled in the spreadsheet.

The operational cost of dashboards, alerts, and incident rituals around billing is real productivity drag. Pricing pages rarely capture that second-order cost.

Pattern 3: Lock-in shows up at exit time

This one shows up again and again in migration post-mortems.

Lock-in is often discovered when leaving—under deadline, with migration budgets that weren't planned for. Architecture reviews rarely simulate "extract my workload in 90 days."

That's the gap tools like Wooven's lock-in auditor are meant to illuminate before exit day.

Pattern 4: The DIY platform temptation

Public "we built our own platform" posts tend to start the same way: We didn't want to. But…

Teams don't aspire to become platform engineers. They end up there when off-the-shelf options feel like renting without ownership, or when bills and boundaries stop making sense.

That tension is why categories like self-hosted panels and sovereign deployment control planes exist alongside hyperscale SaaS.

What people actually ask for

Across those patterns, requirements converge:

Predictable costs (not necessarily the lowest—forecastable)
Visible infrastructure (know where compute and data land)
Portable workloads (leave without a full rewrite)
Strong developer experience on the happy path

The fourth item is usually non-negotiable in 2026: nobody wants to trade UX for sovereignty unless they absolutely must.

The question

Which of these four sits closest to your team right now?

If you're open to being quoted in a future, attributed follow-up, get in touch—I'm collecting permissioned examples only; nothing anonymous passed off as research.

If predictable, visible, portable infrastructure with a polished DX sounds aligned with how you work, wooven.dev has a waitlist.

Sources and methodology

Method: Synthesis of publicly readable threads and articles (migration stories, billing debates, vendor exits), plus informal conversations when engineering leaders bring the topic up—not a statistically sampled survey and not a claimed interview study.
Why this matters: Verifiable patterns beat fabricated authority. If we publish attributed interviews later, they'll be labeled as such with permission.