You spent your evenings and weekends building something. It works. You’re reasonably proud of it. And now you’re staring at a blank LinkedIn post, trying to figure out how to tell people about it without sounding like one of those people.

You know the ones. “After 6 months of grinding, 200 cups of coffee, and a dream that wouldn’t die, I’m THRILLED to announce the launch of my passion project.” Complete with a photo of them grinning at a laptop in a coffee shop that costs twelve quid for an oat milk flat white.

There’s a wide gap between that and saying nothing at all. Your side project is genuinely good LinkedIn content — it’s specific, it’s real, it shows initiative, and other developers actually want to hear about it. The trick is talking about it like a person rather than a startup founder who’s read too many Y Combinator blog posts.

Why side projects make great LinkedIn content

Most LinkedIn content from developers falls into two categories: job announcements and reshared articles. Neither is particularly interesting. Side projects sit in a sweet spot that both categories miss.

A side project post tells people what you can build, what problems interest you, and how you think about technology — all in a single update. It’s more revealing than a CV bullet point and more credible than a self-assessment. You’re not claiming you’re good at React; you’re showing a thing you built with React that solves a real problem.

Side projects also invite conversation in ways that job announcements don’t. People want to know about the technical choices you made. They want to ask about the stack. They want to tell you about a similar thing they built, or suggest a feature, or point out that your landing page has a typo. That kind of engagement is genuine — it comes from developers who are genuinely interested, not from people running an engagement pod.

The content practically writes itself, too. You made decisions while building. You chose one technology over another. You hit a wall and found a way around it. You shipped it and some people used it and some things surprised you. Every one of those is a post.

The painful version vs the good version

Let’s look at what most people write versus what actually works.

The painful version:

Thrilled to announce the launch of my passion project! After countless late nights and buckets of coffee, I’m proud to say that my hard work has finally paid off. Introducing ProjectName — a revolutionary tool that’s going to change the way developers think about [category]. This has been an incredible journey and I couldn’t have done it without the amazing support of my network. Please check it out and let me know what you think!

Everything about this is wrong. “Thrilled to announce.” “Countless late nights.” “Revolutionary.” “Incredible journey.” “Amazing support of my network.” It reads like it was generated by feeding ten thousand startup launch posts into a blender. There’s no information here. The reader finishes the post and knows nothing about what the project actually does, why it exists, or why they should care.

The good version:

Built a CLI that converts Figma tokens to CSS variables. Took a weekend. Already using it on 3 client projects.

The problem: our designers keep updating the design system in Figma, and every time they do, someone has to manually update the CSS variables. It’s boring, error-prone, and takes about an hour each time.

The tool watches a Figma file via the API, diffs the token changes, and spits out a CSS file. One command. Runs in CI if you want it to.

It’s open source: [link]

This version is shorter, more specific, and actually tells you something. You know what it does (converts Figma tokens to CSS variables), why it exists (manual updates are tedious), how it works (Figma API, diffs, CLI), and what you can do with it (it’s open source, go look at it). The “took a weekend” detail is quietly impressive without being a humble-brag — it signals that this is a focused tool, not a six-month odyssey.

The difference between these two posts isn’t writing talent. It’s knowing what to include and what to leave out.

What to include

Keep it to four elements. You don’t need all of them in every post, but these are the ingredients that make a side project post work.

What it does, in one sentence. “A VS Code extension that generates TypeScript types from your API responses.” If you can’t describe your project in a single sentence, you don’t understand it well enough yet — or you’re trying to do too many things. This sentence is the foundation of your post. Everything else builds on it.

Why you built it, in one sentence. “Got tired of manually writing types for every new endpoint.” The motivation matters because it tells the reader whether this project solves a problem they also have. If it does, they’ll keep reading. If it doesn’t, they’ll scroll past, which is fine — you want the right audience, not the biggest audience.

One interesting technical detail. Not a full architecture overview. One thing. “It uses the TypeScript compiler API to infer nested types, which was a nightmare but works surprisingly well.” This is the part that makes other developers lean in. It’s the difference between a product announcement and a developer talking about building something.

The result or what you learned. “40 stars on GitHub in the first week” or “Learned that the Figma API rate-limits you at 30 requests per minute, which changes how you design the polling” or “Three people have already submitted PRs.” A result grounds the post. It tells the reader that this isn’t vapourware — it’s a real thing that exists in the world and has been touched by other humans.

What to leave out

The journey narrative. Nobody needs to hear about the late nights, the self-doubt, the moment you almost gave up, and the inspirational turning point where you pushed through. That’s a TED talk structure, not a LinkedIn post. You’re announcing a tool, not auditioning for a Netflix documentary.

The hustle framing. “Built this while working a full-time job, training for a marathon, and raising twins.” The implication is that you’re more dedicated or harder-working than the reader, which is not a great way to build goodwill. It also invites the reasonable question: is this project any good if you built it in stolen minutes between other commitments?

The humble-brag about sacrifice. “Gave up my weekends for three months” is not the badge of honour people think it is. In a profession that struggles with burnout, romanticising overwork is tone-deaf at best and harmful at worst. If your project took three months of weekends, just say “been working on this for a few months.” The timeline is useful context without the martyrdom framing.

The premature scaling language. Don’t call it a “platform” if it’s a script. Don’t say “we” if it’s just you. Don’t describe your roadmap as if you’re pitching Series A investors. The post should match the scale of the project. Underselling is always better than overselling, because the reader adjusts their expectations downward from whatever you claim.

Templates for different stages

Your side project isn’t a one-post thing. It goes through stages, and each stage has its own post.

Pre-launch. Share what you’re building and why, before it’s done. “Working on a tool that [does thing]. The idea came from [specific frustration]. Early version handles [scope]. Hoping to release it next month.” Pre-launch posts are low-pressure because you’re not asking anyone to use anything yet. They’re also useful for getting early feedback — someone might point out an existing tool that does the same thing, which saves you time. This is building in public at its most practical.

Launch day. The post we’ve been talking about. What it does, why, one technical detail, a link. Keep it short. Resist the urge to oversell. Your project’s quality speaks for itself — if it doesn’t, no amount of enthusiastic copywriting will fix that.

Milestone. “The Figma-to-CSS tool hit 500 downloads this week. Didn’t expect that. The most-requested feature so far is [thing], which I’m working on now.” Milestone posts work because they show traction and ongoing development. They’re also an opportunity to credit the community or share a surprising data point. The key is picking milestones that actually mean something. “100 GitHub stars” is interesting. “Published version 0.0.3” is not.

Pivot. “Started building a desktop app. Halfway through, realised it should be a CLI. Here’s why I switched.” Pivots are interesting because they show decision-making. The developer audience respects someone who changes direction based on evidence rather than stubbornly building the wrong thing.

Shutting it down. The most underrated side project post. “Killed the project I’ve been working on for 6 months. The core assumption was wrong — turns out developers don’t actually want [thing], they want [other thing]. Here’s what I’d do differently.” Post-mortems are some of the most valuable content on LinkedIn because almost nobody writes them. Everyone shares launches; almost nobody shares failures. If you do, you’ll stand out, and the post will probably outperform your launch announcement.

Getting the first draft done

The hardest part of posting about your side project isn’t knowing what to write — it’s sitting down and writing it. The gap between “I should post about this” and “I’ve actually posted about this” is where most side project content dies.

If your side project has a URL — a landing page, a GitHub repo, a Product Hunt listing — you can paste it into ShipPost’s URL mode and get multiple post variations back in seconds. The tool reads the page, understands what the project does, and generates posts in a developer voice with real specifics pulled from your content. It’s not going to write a perfect post — you’ll want to edit, add your own voice, swap in details only you know — but it collapses the “staring at a blank screen” phase into something more like editing, which most people find much easier.

You can also check out the developer LinkedIn post examples we’ve collected for more inspiration on structure and tone.

The point is: you built something. That’s already the hard part. Writing a few sentences about it shouldn’t be the thing that stops other people from discovering it.

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