How to promote your SaaS without being an ass?

I once spent an entire Saturday fine-tuning a landing page animation. It looked slick, sure, but it didn’t move the needle one bit on sign-ups. That’s when the reality hit me: promotion is about solving somebody else’s business headache, not polishing my own ego (I still slip up — old habits die hard).

Since then I keep three guardrails in mind whenever I talk about a product in public. They’re not commandments, more like bumpers in a bowling alley that stop me from swerving into “look at me” territory:

1. Lead with actual, usable value.
2. Work in the open so people can see the messy middle, not just the highlight reel.
3. Show up in communities as a human first, founder second.

Providing value to users

The fastest way to look like an ass is to broadcast product links without context. I did that once on Hacker News and the thread torched me inside five minutes. Now I start with the pain point. Last quarter, for example, our team battled an AWS-native ETL pipeline that quietly dropped rows whenever a lambda timed out (I learned about it from a colleague — never fun). I wrote a post-mortem, shared the fix script, and only at the very end mentioned that our SaaS now alerts on that exact failure mode. The article seemed to generate interest, as we noticed an uptick in trial requests. Correlation isn’t causation, but I’m keeping that playbook.

One more thing: be transparent about dependencies. If your magic feature only works because everything is glued to AWS, say so, and give users an exit path. Nothing nukes trust faster than hidden vendor lock-in (been there, spent the credits).

(I could be wrong, but focusing on code elegance rarely wins hearts on its own. Customers care about the spreadsheet column called “cost saved” more than that clever dependency injection.)

Building in public

I used to hoard progress updates until launch day, thinking secrecy was a moat. Turns out the moat mostly kept feedback out. These days I ship screenshots, revenue graphs, and the occasional face-palm bug on Twitter as soon as they happen. It’s not just vanity metrics. Real humans reply, “I had the same bug,” or “Try Hotwire, it’s two files instead of a React carnival.” Half our feature backlog now comes from those threads.

Benefits, in no particular order (and definitely not a complete list):

1. Credibility through scars and successes. People relate to the 404 pages you fixed at 2 a.m. more than the victory lap.
2. Instant product-market radar. Show the rough prototype, watch the reactions, course-correct before burning another sprint.
3. Serendipitous partnerships. Other SaaS builders will slide into your DMs with integration ideas — just keep the coupling loose so neither side gets trapped.
4. On-ramp for newcomers. When you document in something approachable (Rails + Hotwire is my go-to), folks can replicate it in a weekend and become advocates.

I’m not entirely sure this scales once you hit enterprise NDAs, but up to a significant ARR, it’s been beneficial for us.

Participating in online communities

Communities are the ultimate BS detector. If you waltz into /r/tech with a promo code and no prior karma, expect the downvote hammer. The safer approach: lurk, learn the local jokes, answer a question or two with something genuinely useful. I keep a library of copy-paste snippets—small SQL queries, Terraform templates, even a Notion doc for GDPR intake. Dropping one of those into a thread beats a glossy hero screenshot every time.

Places worth hanging out (pick one or two, not all six—spread too thin and you’ll ghost them the moment road-map panic hits):

1. Indie Hackers build logs. Low-ego, high-signal.
2. Reddit niche subs—post the ugly WIP, not the polished launch GIF.
3. Hacker News “Show HN” when you’re ready for blunt feedback.
4. Product Hunt if you’ve got a one-liner that resonates. Otherwise it’s tumbleweeds.
5. Twitter threads with code snippets literate enough to copy-paste.
6. Specialized forums (think Ops, Infosec, ML) where becoming the “oh-that-person-knows-this” pays dividends.

This worked for me and a handful of projects I’ve advised. It might flop in a different niche, so calibrate constantly.

That’s pretty much my checklist. Keep it useful, keep it honest, resist the urge to over-optimize the code while the business case is still shaky. And if you figure out a better way, ping me—I’ll happily steal it (with credit, promise).