Content distribution for engineers who hate marketing

Most engineers I know ship a side project, paste a link in one Slack and one Reddit thread, watch the analytics for 48 hours, and then quietly conclude that nobody wants what they built.

Usually that's wrong. Usually the project is fine. The distribution was the problem.

The gap between "I shipped it" and "people use it" is mostly content — written, posted, and tuned for the platform it lands on. That's the part engineers reflexively call "marketing" and then refuse to think about, because the word makes us feel like we're about to wear a polo shirt.

I've reframed it. It's not marketing. It's a build pipeline that produces words instead of binaries, and the same instincts that make you a decent engineer make you decent at it. Treat the inputs as data, the prompts as code, and the platforms as targets with different APIs and constraints. Suddenly the whole thing is tractable.

This is the loop I run after every launch. It takes about 2-3 hours total, spread over a week, mostly assisted by an LLM with a few sharp prompts.

Step 1: Write the artefact once. Properly.

Before you touch a single platform, you need one canonical piece of writing about the thing you shipped. Not a tweet. Not a LinkedIn post. A 600-1200 word artefact that lives on your own domain (a blog, a docs page, a project README, doesn't matter — somewhere you control).

Why? Because every other piece of content you generate from here is a derivative of this artefact. If the artefact is mush, every derivative is mush, and you spend the next week chasing your tail trying to fix it on each platform individually.

The artefact should answer four questions in order:

1. What problem does this solve? Specific, in the user's language, not yours.
2. What did you actually build? Concrete description, not features.
3. Why is your approach different from the obvious alternatives? This is where engineers usually have a strong opinion and don't know it's interesting.
4. What does it look like to use it? Show, with a real example.

If you can't fill in those four sections without hand-waving, you don't have a launch problem. You have a positioning problem. Stop and fix that first, because no amount of clever Twitter copy rescues a fuzzy artefact.

Step 2: Stop writing platform copy as a single string

This is where the engineering instinct pays off. Don't write a tweet. Don't write a LinkedIn post. Write a structured payload that knows what it's for.

For any post, the inputs are something like:

- platform: "twitter" | "linkedin" | "reddit" | "hn" | "devto"
- audience: who reads this platform when they're in the relevant headspace
- artefact_url: the canonical link
- one_sentence_pitch: extracted from the artefact, ~25 words
- contrarian_take: the part of your approach that disagrees with the default
- proof_point: one concrete fact (a number, a benchmark, a screenshot)
- voice: terse and dry | analytical | story-led | pure technical

Now your prompt to the LLM isn't "write me a tweet about X." It's: given these structured inputs, write three drafts in voice for platform that get from one_sentence_pitch to artefact_url in the way that platform's audience actually reads.

The outputs are immediately better, and more importantly, they're consistent across platforms. The LinkedIn post doesn't accidentally talk like a Reddit comment. The HN submission doesn't smell like a marketing email.

Step 3: Match the post shape to the platform, not the other way around

Each platform has a native shape. If you fight it, the algorithm punishes you and the readers ignore you. The shapes that have actually worked for me:

• Twitter/X: A single self-contained tweet (no thread) that pairs the contrarian take with the proof point and ends with the link. Threads work too, but only if the artefact genuinely benefits from being unpacked — most don't.
• LinkedIn: 4-6 short paragraphs. Story-led opener ("Last week I shipped X and discovered Y"), then the contrarian take, then the proof point, then a single line CTA. No emoji. No hashtags below 5.
• Reddit: Long-form post in the relevant subreddit, written like a forum reply, not a sales pitch. Lead with the problem, walk through your solution, link to the artefact at the bottom as "more details if useful."
• Hacker News: One-line submission with the artefact URL. Don't write a separate description. Let the title and the artefact do the work. Reply to the first comment with context only if it asks for it.
• Dev.to / Medium / Hashnode: Republish the artefact verbatim with a canonical_url pointing to your own domain. Don't try to rewrite it for each platform.

Notice that the work compounds. The 1,000-word artefact becomes (a) the Reddit post body, (b) the Dev.to/Medium republish, (c) the source of every shorter-form derivative. You wrote it once. It runs on five surfaces.

Step 4: Have one prompt per platform

This is where most engineers stop, ship a generic ChatGPT post, and then complain that AI-written content is bland. AI-written content is bland because the prompt is bland. The fix is to write your prompt once, properly, save it, and reuse it.

My LinkedIn prompt is roughly:

You are writing a LinkedIn post for a senior engineer audience.

Constraints:
- 4-6 short paragraphs, max 1,300 characters total
- Story-led opener anchored in a specific moment, not a general claim
- One contrarian or non-obvious idea, stated directly without hedging
- One concrete proof point (number, benchmark, screenshot reference)
- No emoji, no hashtags, no "In this post we'll cover"
- End with a single open question or a soft CTA, not a sales close
- Match the engineer voice: terse, factual, no hype words

Inputs:
- one_sentence_pitch: ...
- contrarian_take: ...
- proof_point: ...
- artefact_url: ...

My Twitter prompt is different. My Reddit prompt is different again — it has a longer constraint about not sounding like a marketer ("if a sentence could appear in a press release, delete it").

You will spend an afternoon getting these prompts right. After that, every launch costs you ~10 minutes of writing per platform instead of a full evening of staring at a blinking cursor.

Step 5: Write the next artefact while the first one is still spreading

The single best thing you can do for distribution is have more than one thing to talk about.

A single launch post is fragile. One algorithm update, one bad timing, one off-topic news cycle and it's invisible. A second post a week later that references the first, and a third the week after that, and a fourth the week after that, builds a cumulative footprint that's basically unkillable. Each post drives a little traffic to its predecessors. The artefacts compound.

What counts as a follow-up? A post-launch retro. A bug you found that turned out to be interesting. A deeper dive on the contrarian take. A user case study (real, not made up). The launch is an event. The follow-up posts are the dripfeed that turns the event into a presence.

Treat your distribution like you treat your codebase. One commit doesn't make a project. The graph of commits over time does.

What you actually need to start

1. The four-question artefact, written and hosted on your own domain.
2. The structured-input format for posts (the one above is fine, copy it).
3. Three platform prompts you trust. Pick the three platforms where your audience already lives. Skip the others. Two strong channels beats six weak ones.
4. A two-week rhythm of follow-up posts after every launch.

That's the whole pipeline. None of it requires you to wear a polo shirt.

Going further

If writing your own platform prompts feels like the part you'll keep meaning to do and never actually do, the Content Creator Prompt Bible is the version I'd reach for: 150+ prompts already segmented by platform (Twitter threads, LinkedIn stories, Instagram carousels, email sequences, repurposing chains), each with the bracketed inputs already laid out the way the structured-payload model in step 2 wants them. You paste your inputs in, you get a draft out. $29, lifetime.

But honestly, the structure above is the actual asset. The pack is the lazy version. If you set up the artefact and the three platform prompts properly, you don't need anything else for at least a few launches. The point isn't that distribution is hard — it's that you have to take it as seriously as you took the build.