DEV Community

Cover image for I Was Writing Marketing Posts Disguised as Advice. My Audience Noticed Before I Did.
Germán Neironi
Germán Neironi

Posted on

I Was Writing Marketing Posts Disguised as Advice. My Audience Noticed Before I Did.

I've been building CloudPruneAI, an AWS cost optimization tool, and part of the journey has been figuring out how to talk about it.

Last night I sat down to review our LinkedIn content performance from the past month. What I found made me rethink everything.

The data that changed my mind

We've published about 15 LinkedIn posts since mid-January. Some did well. Some flopped. When I looked at the numbers, a clear pattern emerged:

Posts that worked:

Post Theme Result
"The most expensive mistake I've seen in AWS? 'We'll optimize later.'" Behavioral pattern, no blame 8,100 impressions
CloudWatch logs tip with a CLI command Practical, immediately useful Good engagement
Beta testers request Transparent, asked for help Good DMs

Posts that didn't work:

Post Theme Result
"Most FinOps tools are just expensive dashboards" Adversarial, us vs them Low traction
"Stop buying dashboards. Start deploying fixes." Direct comparison to competitors Low traction
"What if the tool that found the problem also wrote the fix?" Thinly veiled product pitch Low traction

The difference was obvious once I saw it side by side.

What I was doing wrong

I thought I was writing helpful content. But several of my posts were really just marketing wrapped in an opinion format:

The adversarial pattern:

"Other tools give you X. You actually need Y. [Implied: we give you Y]."

It seems clever when you're writing it. But readers see right through it. They scroll past because it feels like an ad, even if you never mention your product.

The disguised pitch:

"What if the tool that found the problem also wrote the fix?"

That's not a question. That's a tagline. And LinkedIn audiences can smell a tagline from three paragraphs away.

What actually resonated

The post that went semi-viral (8.1K impressions for an account with ~500 connections) was this one:

"The most expensive mistake I've seen in AWS? Not the m5.24xlarge someone left running. Not the 10TB of logs. It's this: 'We'll optimize later.'"

Why did it work?

  1. It described a pattern, not a product. Anyone who's worked with AWS recognized the behavior.
  2. It didn't point fingers. No "your tools are bad" or "you're doing it wrong."
  3. It gave something to think about. The reader left with a reflection, not a sales pitch.
  4. It ended with a genuine question. "What's your 'I'll fix it later' that never got fixed?" People wanted to share their own stories.

The voice we're building now

After this analysis, we documented what we're calling our brand voice. The core principle:

"The engineer who's been through this and shares what they learned."

Not a vendor talking to a prospect. A peer sharing a trench.

Five rules we're following now:

1. Experience before opinion

  • Before: "Most FinOps tools are just expensive dashboards."
  • After: "A CTO told me they had 3 dashboards showing $5K in waste. Six months later, nothing changed. I asked why."

2. Give before you ask

Every post should leave the reader with something useful. If someone reads our post and doesn't need our product, they should still feel like they gained something.

3. Show, don't tell

We don't say "we deliver solutions, not dashboards." We tell stories where the gap between knowing and acting cost real money. Our value proposition emerges from the narrative, not from a comparison chart.

4. Vulnerability over perfection

Share mistakes, real numbers, honest doubts. Building in public means actually being public, not curating a highlight reel.

5. Invite conversation, not debate

  • Before: "Agree or disagree?"
  • After: "Has anyone else experienced this?"

One triggers a debate. The other triggers storytelling. Storytelling builds community.

What we stopped doing

We archived several posts that were already written and scheduled:

  • "Hot take: If you're still writing CloudFormation YAML..." → adversarial tone
  • "Stop buying dashboards. Start deploying fixes." → us vs them
  • "What if the tool that found the problem also wrote the fix?" → pitch disguised as reflection
  • "I ran a scan on a fintech's AWS. Found $21K/month in waste." → sounds like a sales demo

Killing content you already wrote is painful. But publishing content that makes people scroll past is worse.

The new content plan

We replaced the archived posts with five new ones that follow the new voice:

  1. "The resource nobody remembers creating" - About orphaned AWS resources and the pattern of "I think someone from the previous team set that up." Practical tips for tagging and monthly cleanup.

  2. "Your staging environment doesn't sleep" - Quick math on how dev/staging running 24/7 wastes 76% of its cost. Practical solution with Lambda scheduling.

  3. "Month 1: $1,974 and zero customers" - Full building in public post. Real investment numbers, what we built, what we got wrong.

  4. "The Friday ritual that saves thousands" - A 10-minute weekly cost review habit anyone can start immediately. No tools required.

  5. "The conversation that changed how I think about cloud costs" - A founder who knows they have waste but doesn't have bandwidth to fix it. The compound effect of "we'll get to it."

Notice the difference: none of these posts require CloudPruneAI to exist. They're useful on their own. That's the test.

Why I'm sharing this

Because I think a lot of early-stage founders fall into the same trap.

You build something you're excited about. You want to tell the world why it's different. So you write posts that explain why your approach is better than the alternatives.

And it feels productive. You're "doing content marketing."

But your audience doesn't care about your competitive positioning. They care about their problems. They engage with content that helps them, teaches them, or makes them feel seen.

The product pitch can come later. First, earn the right to pitch by being genuinely useful.

The real metric

The best signal we've gotten wasn't impressions or likes. It was a DM after the "We'll optimize later" post:

"This is literally what's happening at my company right now. Can we talk?"

That came from a post that never mentioned CloudPruneAI. Never mentioned our product at all.

That's the voice we're building toward.


I'm building CloudPruneAI in public — an AWS cost optimization tool that generates deployable infrastructure-as-code instead of just reports. If you're interested in following the journey, I share monthly updates with real numbers.

This is month 1. Total invested: $1,974.06. Paying customers: 0. Lessons learned: priceless (and free, apparently).

Top comments (0)