Back to notes

November 15, 2025 · 5 min read

A Client Wanted a Cheaper Alternative, Here's How I Explained Why Not

A client found a $30/month tool that looked like it replaced a $400/month vendor. It didn't, and the conversation about why it didn't taught me a better way to have that talk.

FreelanceBusiness

A client sent me a link mid-project: "why are we paying $400/month for this when this other thing is $30?" The other thing did, on its landing page, look like it did the same job. It did about a third of it.

My first instinct was to just say no and move on, which is the fastest way to make a client feel dismissed and start trusting their own googling over your judgment. So instead I pulled up both tools side by side on a call and walked through exactly where the cheaper one would fail for their specific setup — not generically, specifically. Their server-side container needed a vendor with CAPI deduplication support and SOC 2 compliance for the data they were passing. The $30 tool had neither.

A client comparing price tags isn't being difficult, they're doing their job. Your job is to make the comparison apples-to-apples, not to win the argument.

The framework that actually lands

I stopped arguing features and started asking what would specifically break. "If we switch, what happens to deduplication on your ad conversions" is a more useful question than "this tool is better." It turns an abstract price objection into a concrete list of consequences the client can actually weigh against the savings.

  • List the specific capabilities the current tool provides that the project depends on.
  • Check each one against the cheaper alternative explicitly, not against its marketing page.
  • Quantify the gap in terms the client cares about — revenue risk, compliance risk, or hours of rework — not feature-count.
  • If the alternative genuinely covers the gap, say so. Don't defend a tool just because you recommended it.

That last point mattered more than I expected. Halfway through a similar conversation on a different project, I realized the cheaper tool actually did cover what we needed — I'd recommended the pricier one a year earlier when the cheaper one didn't support what we needed yet. Being willing to say "actually, you're right, let's switch" is what made the client trust me on the next five times I said no.

The goal isn't to defend every line item on a stack you built. It's to make sure the client is comparing the right things before they decide, and to be genuinely willing to lose that argument when the math says so.