The "I Switched Payment Processors / CDN / Email Provider" Genre Is Mostly Wrong About What Mattered

Pull up any indie hacker timeline in 2026 and you'll see three flavors of post over and over.

"I switched from Stripe to Polar and saved 40%."

"I left Vercel for Cloudflare and cut my bill 80%."

"I moved off Mailchimp to Resend and finally have working emails."

These threads always hit. They're useful. They're also, in roughly 80% of cases I've audited, wrong about which decision actually moved the needle.

After spending the last week reading 30 of the most-shared "I switched X" posts of the past quarter and lining them up against actual outcomes (where the founders shared follow-ups), the pattern is uncomfortably consistent. Here's the meta-lesson and a much shorter list of the switches that actually paid off.

This post is also self-implicating. I have published, on this blog, exactly the kind of "switched to Astro + Cloudflare" post that earns this critique. I'll get to that.

The pattern, in plain English

"I switched X" posts over-credit the new vendor and under-credit two structural changes that almost always happened at the same time:

The founder did distribution work as part of the migration. Rebuilt the landing page. Rewrote the comparison content. Relaunched on Product Hunt. Sent a "we just migrated" email to the list. Wrote the migration thread itself, which served as content marketing.

The founder simplified their architecture in ways unrelated to the vendor change. Turned off three abandoned preview environments. Cleaned up unused middleware. Fixed an SPF record. Removed three orphaned cron jobs. Killed a feature that nobody used.

The vendor switch usually gets the headline. The simplification and the distribution work do the heavy lifting.

Three concrete examples from the last quarter

Anonymized, but each is a real post I read and traced.

"Switched from Stripe to Polar, MRR up 60% in two months." The founder also rewrote their pricing page and launched on Product Hunt the same week. The Product Hunt launch drove ~600 signups in the launch window, of which ~40 converted. MRR went up because of the launch, not because Polar's checkout converted slightly better. The processor change was a 2% conversion bump in user-testing. The Product Hunt launch was a one-time spike.

"Moved off Vercel, bill dropped 80%." Bill dropped because they also turned off three abandoned preview environments, cleaned up middleware that was being invoked on every request, and removed an analytics integration that was firing 100 events per page load. The CDN change was responsible for maybe 20% of the savings. The cleanup was responsible for the rest. Either change would have produced most of the bill drop alone.

"Resend instead of Mailchimp, deliverability up." They also fixed their SPF record, which had been broken for six months, and stopped sending to a list segment with a 40% bounce rate. Resend's deliverability is genuinely better than Mailchimp's, but the SPF fix and list hygiene were doing the bulk of the work. The same two fixes on Mailchimp would have produced 80% of the gain.

In all three cases, the founder believed the vendor change was the variable. In all three cases, the actual variable was the work the founder did around the vendor change.

The honest list of vendor switches that do move the needle

Not all migrations are theater. There are specific switch categories where the vendor change is genuinely doing the work.

Moving off enterprise-grade tools to indie-grade tools at sub-$10K MRR. Salesforce → Pipedrive. HubSpot Pro → Plain. Confluence → Notion. The cognitive overhead saved is real. Enterprise tools assume a team of 20 with dedicated ops. Indie tools assume a team of 1. The fit difference is genuinely a productivity difference, not a wash.

Moving off self-hosted to hosted for non-core infra. Self-hosted Postgres → Neon. Self-hosted Redis → Upstash. Self-hosted RabbitMQ → SQS. Operational time saved is real. The "I'll save money by self-hosting" math almost never accounts for the 5–10 hours/month you'll spend on maintenance, and that time is worth more than the dollar savings.

Moving off all-in-one platforms to composed primitives when your product is content-led. WordPress → Astro + Stripe + Resend. Squarespace → Astro + Stripe + Resend. The speed gain is real because the all-in-one platforms are slow and the composed-primitives stack is fast. For content-led products specifically, this matters.

Almost everything else is preference dressed up as substance.

The vendor switches that almost never move the needle

Three categories where the switch is mostly theater.

Payment processor (within the major 4–5 options). Stripe, PayPal, Lemon Squeezy, Polar, Paddle, Managed Payments. Your customers cannot tell the difference. Your conversion rates are within 1–2% of each other in any user test. Your bill differences are real but small in absolute dollars. The hours spent migrating them are usually not recoverable.

CDN choice (within the major 3). Vercel, Cloudflare, Netlify. Your end users do not perceive a difference between sub-100ms responses from any of them. Your bill differences are sometimes meaningful (especially with Cloudflare's free bandwidth) but the migration cost is also real. For most workloads, picking one and sticking with it is the right call.

Transactional email provider (within the major 5). Resend, Postmark, SendGrid, Loops, Mailgun. Deliverability differences are real but small if you've configured SPF/DKIM/DMARC correctly. The "Resend is so much better" framing usually elides the SPF/DKIM/DMARC fix that should have happened anyway.

These are commodity layers. Customers cannot tell the difference. Bill differences are real but small. Hours spent migrating are usually not recoverable.

Why the "I switched X" genre persists despite this

It's a low-effort post that gets engagement. People who picked the same vendor like it. People who picked the other vendor argue. The thread reliably gets 100+ replies of either flavor.

It has a clear before/after narrative. "I was on X, I switched to Y, here's what happened" is a structurally simple story shape. Stories with clear before/after states travel further than nuanced "I made several adjustments simultaneously" stories.

The dopamine of a successful migration creates the illusion of significant change. Migrating something feels like progress when the actual product work feels stalled. The migration is concrete. The work it's substituting for is fuzzy. The brain prefers concrete progress.

Indie founders also reach for migration content when they're stuck. If your MRR isn't growing and you don't know why, "let me try a different processor" is a much easier project than "let me figure out why my product isn't growing." The migration is a way to feel productive while avoiding the harder question.

The personal application

I am writing this knowing I have published, on this blog, a "switched to Astro + Cloudflare" post that earns this exact critique.

The honest follow-up is that the migration itself didn't move my numbers. The writing I did about the migration moved them. The vendor was a prop. The audience-building was the point.

Specifically: the migration post itself drove ~3,000 readers in its first week, of which a meaningful fraction subscribed to the newsletter. The Astro/Cloudflare stack itself produced no measurable improvement in any product metric — the page is slightly faster, the bill is slightly lower, none of which my readers can perceive. The migration was a load-bearing piece of content. It was not a load-bearing piece of infrastructure.

This is uncomfortable to admit in public. It's also accurate. The pattern I'm calling out applies to me too.

The right framing

When you find yourself reaching for a migration, ask three questions.

What's the actual product problem I'm trying to solve? If the answer is "my MRR isn't growing," migration is the wrong tool. The right tool is customer development.

What's the distribution work I could do instead? If the migration would generate a "switched to X" post, would the time be better spent writing a "thing I learned from a customer this week" post? Often yes.

What's the architectural simplification I'd do alongside the migration? If you're going to migrate, the actual savings are probably in the cleanup. Do the cleanup, see what's left, then decide if the migration is still worth it. Often it isn't.

The right answer to "should I migrate" is rarely a clean yes or no. It's "what work am I avoiding by spending the weekend on this migration."

The contrarian take

Most vendor migrations are either commodity-layer reshuffling or excuses to do unrelated good work.

The interesting question isn't "which vendor should I pick." It's "what work am I avoiding by spending the weekend on a migration." If the answer is "the architectural cleanup that needs to happen anyway," go do the cleanup, then decide if the migration is still worth it. If the answer is "customer development," go do customer development, then decide if the migration matters.

The work of running a solo SaaS in 2026 is mostly customer development, audience building, and distribution. Vendor migrations are a small fraction of where the leverage actually is. Treat them as such.

When you write the "I switched X" post, do it knowing the post itself is the leverage. The vendor change is the prop. The audience you build by writing about your stack decisions is the actual product of these posts. Be honest about that — both with your readers and with yourself.

The vendors will keep changing. The audience compounds.