How to Launch With a DEV Article: Write Something Worth Reading First
Launch with a DEV article by writing a post that is useful even if the reader never clicks your link: a tutorial, a build story or a lesson, with your product as the worked example. DEV’s terms say content should not be designed primarily for promotion or backlinks and must contain substantial content. Set up the front matter, use up to four tags, disclose AI help and tag the link you include.
What does DEV expect from an article that mentions your product?
Substance first. DEV Community’s terms of use, which we read on 13 November 2026, say users must make a good-faith effort to share content that is on-topic, of high quality and not designed primarily for promotion or for creating backlinks. They add that posts must contain substantial content and may not merely point to an external link that holds the full post, and that affiliate links must be clearly disclosed.
So a launch article on DEV is not a press release. It is a piece a developer would bookmark whether or not they ever try your product. The product appears because it is the example, the tool you used to solve the problem the article describes. If you remove the product name and the article is still useful, you have written the right thing.
Which kind of article should you write?
| Type | What the reader gets | Where the product fits | Best when |
|---|---|---|---|
| A tutorial that solves one problem | A working solution they can copy | As the tool the steps use, shown running | Your product removes a specific chore |
| How I built it | The decisions, trade-offs and dead ends | As the subject, with the interesting parts explained | The build had a hard or unusual part |
| A lesson from the first weeks | What surprised you and what you would change | As the setting for the lesson | You have real results or mistakes to share |
| A comparison of approaches | A fair look at ways to solve a problem | As one option among several, labelled as yours | Developers already search for the problem by name |
Pick the type that your product’s story supports. A developer tool suits the tutorial. A product with an unusual architecture suits the build story. If you are launching an open-source project, a good README is the other half of this work, and the README template for a launch shows what to put in it.
How do you set up the post?
DEV’s editor guide (read 13 November 2026) describes front matter between triple-dashed lines at the top of the editor. The fields it lists include the title, a published flag, a description used in Twitter cards and Open Graph cards, tags with a maximum of four and comma-separated, a canonical URL, a cover image with a best size of 1000 by 420 and a series name. It also says to use a clear, descriptive title with relevant keywords.
--- title: How I turned a folder of invoices into a spreadsheet with one command published: false description: A short walkthrough of the parsing steps, the three formats that broke it and the fix. tags: webdev, opensource, productivity, tutorial canonical_url: https://your-site.example/blog/invoice-parsing cover_image: https://your-site.example/images/cover-1000x420.png series: Building in the open ai_disclosure_level: some_ai ---
- Headings: the guide says not to use a level-one heading in the body, because the title is already the page’s H1. Start with level two.
- Images: write alt text for each, which the guide asks for to help people who use screen readers.
- Embeds: the guide lists tags for embedding a GitHub repository, a YouTube, Vimeo or Loom video, CodeSandbox and StackBlitz demos and more, so a reader can run the thing without leaving the post.
- Drafts: the guide says links to drafts and scheduled posts can be shared for feedback, so ask a colleague to read yours before it goes out.
What about AI help with the article or the product?
Disclose it. DEV’s code of conduct lists following its AI guidelines and disclosing AI assistance used to create content among its standards, and the editor guide lists an AI disclosure field in the front matter with four values: not disclosed, no AI, some AI and fully autonomous. Choose the one that is true. If a coding assistant wrote much of your product, say that in the article as well; readers who build with these tools value an honest account of what worked.
The playbook for vibe coders goes further into how to talk about an AI-built product. Write the article yourself, from your own notes, so the details reflect what happened to you.
Should the article live on your own site as well?
Yes if you can, and set the canonical URL. If the same article is on your site and on DEV, the canonical URL field is how you say which address is the original. Search engines treat it as a hint, not an order, but without it you leave two copies competing. Publish on your own site first, then on DEV with the canonical pointing home, so your own page can earn the search visibility.
That ties into the long game of search. An article that answers one question well on your own site keeps sending visitors long after the DEV post has dropped out of the feed. The SEO from day one playbook explains what to set up so that page can be found.
How do you publish it and know whether it worked?
Publish when you can stay for the replies. We know of no verified best hour on the site, so choose one, note the result and try another next time. Answer every comment, correct any mistake a reader finds and say in the post that you fixed it. A visible correction builds more trust than a post that never changes.
Include one link to the product, in the place where a reader would naturally want it, and tag it so it has its own source in your analytics; the UTM tagging checklist shows how. Measure visits and the share who reach your key action, not reactions, which show that people liked the writing and say little about the product. Then launch your product free on the board and link the article from the description, so the two support each other. For more developer-facing products and ideas, browse the developer tool ideas.
What makes a DEV launch article fail?
- A thin post that exists to carry a link, which the terms say a post must not be.
- A feature list written as a story. Developers can tell and move on.
- Tags that do not fit the content, added to reach a bigger audience.
- No disclosure of AI use, or of a connection to a product you praise.
- No follow-through on comments, which wastes the best part of the format.
Frequently asked questions
Can I promote my product in a DEV article?
You can mention it, but the article must stand on its own. DEV’s terms say content should not be designed primarily for promotion or backlinks and must have substantial content of its own. Write a tutorial or build story where your product is the example, and include one clear link rather than repeating it.
How many tags can I use on a DEV post?
Up to four, comma-separated in the front matter, according to DEV’s editor guide. Choose tags that describe the article’s actual content and the people who would want to read it. Adding unrelated popular tags does not help and can make the post look like it was aimed at the wrong crowd.
Should I post the article on my own blog as well?
If you have a site, yes, and set the canonical URL on DEV to your own page so the original is clear. Publish on your site first, then cross-post. If you have no site yet, DEV is a reasonable home, though you do not own the page and the audience is DEV’s.
Do I have to say that AI helped write the code or the post?
DEV’s code of conduct asks contributors to follow its AI guidelines and disclose AI assistance used to create content, and the editor has a disclosure field with set values. Be honest in that field and in the text. Readers react far better to a candid account than to a discovery later.
Written by Post your build ideas with AI assistance and edited for this site. Where a page names another product, the facts came from that product’s own pages on the date shown above; terms change, so check them before you rely on them. About the publisher.