I pulled 1,033 posts off DEV.to across 11 tags. 634 of them went up in the previous ten days.
578 of those 634 — nine in ten — got three reactions or fewer and not a single comment.
I did it twice, two days apart, on different windows. 89.6% the first time, 91.2% the second. It's not a bad week. It's the normal outcome.
I expected to find that the quiet posts were about weaker projects. That is not what I found. Some of the most interesting things I read all month were sitting at zero.
So I started reading them properly, looking for what the quiet ones had in common. There's a pattern, and it isn't about the algorithm or posting times or whether you used the right hashtag.
Almost everyone leads with the wrong sentence.
1. The differentiator is buried
Jakub Melka wrote a C++ library that reads and writes Word, Excel and PowerPoint files. His post opens by explaining there's no feature-rich C++ library covering all three formats.
Nine paragraphs down, under a bullet list of features, is this:
"When you open a document with charts, SmartArt or custom extensions, the usual question using open source libraries is, what will I lose? In ExyokiOffice, unknown content is preserved in the internal XML DOM tree during the modification and then saved back."
That's the whole thing. Most libraries silently drop what they don't understand, and you discover it three steps later when something downstream is missing. His doesn't. That is a much better sentence than "feature-rich," and it's the ninth thing he mentions.
Marcello Samiandrisoa built a Markdown editor under 10MB with Tauri and Angular. Good, but "lightweight Markdown editor" is a crowded shelf. Under a heading near the bottom called Where you can get it, you find out he got it through Microsoft Store certification and ships .dmg, .deb and .rpm as well.
Most "I built a lighter X" posts end at a GitHub link. He shipped to an actual app store and mentioned it last.
2. Described, not differentiated
Muhammad Irva builds gRPC services at a fintech in Jakarta and got tired of API clients eating his RAM, so he wrote his own. He knows the space is crowded — his title literally says Why I Built Yet Another API Client.
His post lists auth methods, gRPC reflection, a mock server, OpenAPI contract checks. All fine. All things other clients do.
Then, as the third sub-bullet of a section about git:
"Secrets auto-split into a
.gitignored file, so they never end up in your commit history"
Anyone who has ever committed a Postman export with a live bearer token in it just sat up. That is the sentence. It's a sub-bullet.
3. Assumed it was obvious
This one is the most common and the most costly, because the thing you leave out is usually the thing you worked hardest on.
Om Uniyal built a terminal SQL workspace for data files. Partway through his post there's a section headed The part I didn't plan: while testing, he loaded a real file from work and found a number sitting in a gender column. So he made the tool scan for that automatically — structural errors and type anomalies, filed into an errors table you can query.
Later he asks himself the obvious question — why not just use DuckDB directly? — and answers it with workflow. But he'd already answered it better two sections earlier. DuckDB's CLI will not tell you there's a number in your gender column. That's the reason, and he filed it under an accident.
Hassan Magdy's is the sharpest example of the pattern. He opens his post with the problem that made him build a 2FA app: getting locked out of your accounts after resetting your phone. Strong opening — it's a real fear.
Then, near the bottom, under Ironclad Features:
"To prevent accidental deletion, users must re-enter their master password before removing any 2FA account."
Accidental deletion is how people actually lose 2FA access. More often than a lost phone. He built the guard for the exact problem he opened with, and never connected the two.
What these have in common
None of these people are bad writers. The posts are clear, well-organised, and honest.
The problem is structural: you cannot see your own project from outside. After six months in a codebase, the hardest thing you solved stops feeling like an achievement. It's just how the thing works now. So it goes in a bullet list, or gets left out, and "feature-rich" goes at the top because it sounds like what a launch post says.
The fix isn't writing better. It's a question:
What can my project do that the obvious alternative can't?
Answer that in one sentence, put it first, and delete the adjectives. If your answer is "it's faster" or "it's lightweight," you haven't found it yet — go further down your own post. It's usually already in there.
The disclosure, so it isn't strange
I build a tool that does this for people. It reads a project and writes the launch post around whatever's buried in it.
I'm not a developer. I'm a contractor in Michigan, which turns out to be the useful part — I can't build what these people build, so all I can do is read it from outside and notice what's good. That's the part that's hard when it's yours.
If you shipped something and it landed to silence, post the link below. I'll tell you what you buried. No charge, no signup, and you don't have to use it.
The five projects above are all worth a look, and none of them are affiliated with me:
- ExyokiOffice — native C++ for DOCX, XLSX and PPTX
- Markify — Markdown editor under 10MB
- Relay — native API client, git-friendly
- duckboard — file-first SQL workspace
- OtpVault — zero-knowledge 2FA
Top comments (0)