You built something. Maybe it’s a SaaS tool, maybe it’s a library, maybe it’s a side project that turned into something people actually use. It works. You’re proud of it. And now comes the part you’ve been dreading: you need users.

The word “marketing” makes your skin crawl. You picture someone in a WeWork writing “synergy” on a whiteboard. You think about growth hacks, engagement pods, posting cadences, and personal brands. You imagine yourself writing “I’m thrilled to share…” on LinkedIn and feel physically ill.

Good news: that’s not marketing. That’s a caricature of marketing that developers have rightfully learned to despise. Actual marketing — the kind that works for developer tools and technical products — looks nothing like that.

It looks like talking about your work.

The developer’s marketing paradox

There’s a specific paradox that trips up technical founders and indie developers. You spent months or years building something genuinely useful. You understand the problem space deeply. You’ve made dozens of interesting technical decisions along the way. You’ve solved real problems.

And yet, when it’s time to tell people about what you built, you freeze. Because “telling people about what you built” triggers the marketing reflex, and the marketing reflex says you should write a landing page with social proof and a hero section and three pricing tiers and a “book a demo” button.

That stuff has its place. But it’s not where your first users come from. Your first users come from other developers who trust you because you’ve shown your work. They tried your thing not because of a landing page, but because they saw you post about an interesting technical decision and thought “this person knows what they’re doing.”

The paradox resolves when you realise that the work itself IS the marketing. You don’t need to put on a different hat. You just need to share the hat you’re already wearing.

Let’s get specific, because “share your work” is the kind of advice that sounds great until you sit down to do it and realise you have no idea what to post.

Technical decisions and trade-offs. Every project involves choices. You picked Postgres over MongoDB. You chose server-side rendering over a SPA. You wrote your own auth instead of using a service. Each of these decisions has a “why” behind it, and that “why” is interesting to other developers facing the same choice. Post about it. Not as a tutorial — as an explanation of your reasoning. “We went with SQLite for our desktop app because we needed offline support and didn’t want to maintain a sync layer. Here’s how that decision has held up after six months.”

Performance improvements with real numbers. “We reduced our API response time from 800ms to 120ms by adding a Redis cache in front of our most expensive query.” Developers love numbers. Specific, concrete numbers that demonstrate cause and effect. This isn’t marketing copy — it’s an engineering result. But it markets your competence (and your product) more effectively than any landing page ever could.

Tool choices and workflows. “We switched our CI from GitHub Actions to Buildkite because our test suite was hitting the Actions concurrency limit. Here’s our config.” This kind of post serves double duty: it’s useful to anyone considering the same switch, and it signals that you’re building something real enough to have CI scaling problems.

Mistakes and lessons learned. Counter-intuitively, posting about what went wrong builds more trust than posting about what went right. “We shipped a migration that corrupted 2% of user records. Here’s how we caught it, fixed it, and what we changed to prevent it.” Vulnerability — real vulnerability, not the performative LinkedIn kind — is compelling because so few people do it.

None of these posts mention your product’s pricing page. None of them ask people to sign up. None of them include a “link in comments” call to action. And yet every single one of them is marketing. Because every single one of them makes someone think “I should check out what this person is building.”

Why this works when traditional marketing doesn’t

Developers have finely tuned hype detectors. Years of being marketed to by enterprise sales teams, DevRel campaigns, and “10x your productivity” ads have made the average developer deeply sceptical of anything that smells like a pitch.

When you post a traditional marketing message — “Introducing Product X: the fastest way to do Y” — a developer’s first instinct is suspicion. Fastest? Prove it. Who’s paying for this post? What’s the catch? The guard goes up immediately.

When you post about a technical decision, a performance improvement, or a lesson learned, the guard stays down. You’re not selling anything. You’re a developer talking to other developers about developer things. The product context is incidental. “We built this, here’s an interesting thing about how we built it.” The trust is earned through demonstrated competence, not through claims.

This is why building in public works so well as a growth strategy for developer tools. The transparency itself is the differentiator. In a market full of products with polished landing pages and no visible engineering, the one where you can see the founder talking about their actual codebase stands out.

The anti-marketing playbook

Here’s the framework distilled down to something actionable.

Post about what you build. New features, architectural changes, refactors, migrations. Anything that changed this week. You don’t need to make it sound impressive — just describe what happened and why.

Post about how you build it. Your stack, your processes, your tooling decisions. Developers are endlessly curious about how other developers work. Your workflow is content.

Post about what you learn. Bugs, outages, wrong assumptions, things you’d do differently. The learning is the point, and it’s universally relatable.

Never post about why people should buy your thing. Seriously. Never. The moment you switch from “here’s what I built” to “here’s why you need what I built,” you’ve lost the trust differential that makes this whole approach work. Let people draw their own conclusions about whether your product is useful. If you’re posting interesting technical content about it, they will.

This playbook works on both LinkedIn and X, though the execution differs by platform. We broke down how to approach each one in a separate post. The short version: LinkedIn rewards the narrative, X rewards the hot take. Same source material, different framing.

The compound effect

The thing about this approach is that it compounds. Your first five posts might get 20 likes each. That’s fine. Those 20 people are now aware of you and your project. Some percentage of them follow you. Your next five posts reach more people because your audience has grown. Some of those people share your posts. The graph bends upward, slowly and then faster.

After six months of consistent posting about your work, you’ve built something more valuable than any ad campaign: a reputation. People in your niche know your name, know your project, and trust your judgement. When someone asks “what should I use for X?” in a Slack group or Discord, your name comes up — not because you asked anyone to mention you, but because they’ve been reading your posts.

This is how most successful developer tools grow in their early stages. Not through Product Hunt launches or HackerNews frontpage hits (though those help), but through the slow accumulation of trust built by showing up, sharing your work, and being genuinely useful to a specific community.

The side project approach to LinkedIn is built on exactly this principle. You don’t need a marketing department. You need to be interesting, and you already are — you’re building things. You just need to talk about it.

The ShipPost pipeline

If the barrier to posting is the writing itself — you know what you want to say but staring at a blank text box is painful — that’s a solvable problem.

ShipPost’s core pipeline is: merge a PR, scan your repos, pick the PRs worth posting about, and generate a post. The AI has your PR context — the title, the description, the diff — so the output is grounded in what you actually shipped, not in generic templates.

The system prompts are specifically tuned to produce the kind of content we’ve been talking about: technical, specific, human-sounding, and free of the corporate LinkedIn register that developers rightly ignore. No “thrilled to announce.” No “excited to share.” Just a developer talking about what they built.

You can see how the full PR-to-post pipeline works and there’s a more detailed comparison with ChatGPT if you want to understand how the prompts differ from what you’d get with a generic AI tool.

The key insight is that the writing doesn’t have to be the bottleneck. You’ve already done the interesting part — the building. Turning that into words is a mechanical problem, and mechanical problems are exactly what tools are for.

You’re already doing the hard part

Here’s the reframe that matters. You’re not “doing marketing.” You’re not “building a personal brand.” You’re doing the same thing you’ve always done — building software — and occasionally telling people about it. That’s it.

The developers who grow their products this way don’t identify as marketers. They identify as builders who happen to share their work. The sharing is a side effect of the building, not a separate discipline.

If you’re reading this and thinking “but I’m not interesting enough to post about,” you’re wrong. You’re building something. You’re making decisions. You’re solving problems. That’s inherently interesting to other developers who face similar decisions and problems. You don’t need to be building the next Kubernetes. You need to be honest about what you’re building and why.

The marketing is already done. You just haven’t posted it yet.

Try ShipPost free — no credit card, no subscription. Bring your own API key.

Side Project LinkedIn Posts — specific tactics for posting about projects you’re building
Building in Public on LinkedIn — the broader strategy behind sharing your work
Turn PRs into Posts — the ShipPost workflow for turning your code into content