Content Publication Guidelines

These are the rules an editor checks your draft against. They are deliberately specific: most rejections are for things on this page, and almost all of them are fixable before you hit submit.

This page covers how to write a submission that gets accepted. For how we review, label sponsored content, handle AI disclosure and issue corrections, see Editorial Standards. For how to sign up and submit, see Write for Us.

We publish practical, experience-backed writing for developers, founders and engineers. The test we apply is simple: would someone doing this work actually learn something?

Topics we actively want:

• AI & machine learning: applied, not speculative
• SaaS engineering, product and operations
• Developer tools and workflow
• Cybersecurity and privacy engineering
• Cloud infrastructure and architecture
• Startup growth, hiring and technical leadership

Angles that consistently do well: a decision you made and what it cost, a migration with real numbers, a postmortem, a comparison you actually ran, a thing that broke in production and what you changed.

Submissions must be original and previously unpublished. That includes your own blog, Medium, Dev.to, LinkedIn articles and your company's site. We do not accept syndicated or reposted content.

After publication, you are free to link to the article anywhere. If you want to republish the full text elsewhere later, please add a canonical link back to the ModernTechLap URL so search engines know which came first.

Plagiarised or spun content is rejected and the account is closed. This is the one rule with no second chance.

• 1,200–2,500 words for most articles. Shorter is fine if the piece is genuinely complete; padding to hit a number is obvious and counts against you.
• A clear H1 title, then H2 sections and H3 subsections. Do not skip heading levels.
• An opening that states what the reader will get. No 200-word throat-clearing about how “in today's fast-paced digital landscape…”
• Short paragraphs. Three or four sentences is plenty.
• A closing section with the actual takeaway, not a summary of what you just said.

Claims of fact need support. Benchmarks, pricing, market figures, security claims and “X is faster than Y” all need a source or your own reproducible method.

• Link to primary sources: documentation, the paper, the changelog: not to a blog summarising them.
• Give the date for anything time-sensitive. Pricing and benchmarks go stale.
• If the data is yours, say how you produced it: versions, hardware, sample size.
• Do not invent statistics. An unsourced number is treated as fabricated.

You get a dofollow link on your author profile: that is the standard deal for a guest post, and it is not conditional on anything in the article body.

• Up to two links to your own site in the body, and only where they genuinely support the point.
• Commercial and promotional links are marked rel="sponsored" or rel="nofollow" at our discretion.
• No affiliate links, link exchanges, or links inserted on behalf of a third party.
• Anchor text should describe the destination, not be stuffed with keywords.

Articles written primarily to place a link are rejected. If the piece would not exist without the link in it, an editor will notice.

• Code goes in fenced code blocks with the language set. It must run: reviewers check.
• Images should be your own, licensed, or clearly attributed. Include descriptive alt text; it is an accessibility requirement, not an SEO field.
• Screenshots must not contain API keys, tokens, customer data or personal information.
• Tables for comparisons. Lists for steps. Prose for reasoning.
• No emoji in headings, no ALL-CAPS, no keyword-stuffed subheadings.

Write like a practitioner explaining something to a colleague. First person is fine. Opinions are welcome when you argue for them.

Avoid marketing register: “revolutionary”, “game-changing”, “seamless”, “unlock the power of”. If a sentence would fit in a product brochure, cut it.

Tell us up front if you have a material relationship to anything you write about: you work there, you hold equity, you were paid, or you are writing on a client's behalf. Disclosure does not usually stop publication: an undisclosed conflict discovered later does, and the article comes down.

Paid placements go through Paid PR, are labelled as sponsored, and are never presented as editorial. See Editorial Standards for how that labelling works.

Articles publish under a real person. A byline that cannot be checked is worth nothing to a reader, and it is the thing search engines and AI assistants use to decide whether an article carries any weight.

Required

• Your real name.Not a company name, not a pen name, not “Editorial Team”.
• At least one professional profile we can check: LinkedIn, GitHub, a personal site, or a public author page elsewhere. It has to be a profile you control and that a stranger could use to confirm you are who the byline says.
• Your role and company at the time of writing. If that changes later, the article keeps the role you held when you wrote it, and the profile shows the current one.
• A verified email address. Corrections and right-of-reply requests have to reach you.

What goes on your profile page

Your name, bio, role, the articles you have published here, and one followed link to your own site. Any professional profile you give us is published as a machine-readable sameAs link, which is how a search engine ties this byline to the same person elsewhere. We only ever publish links you have given us.

Not accepted

• Ghostwritten articles submitted under someone else’s name.
• Bylines for people who did not write, or at minimum direct and check, the piece.
• One account submitting under several invented author identities.

Using an AI tool to draft, edit or research is allowed. Publishing its output unverified is not.

You are responsible for every factual claim, citation and code sample in your submission. AI-generated citations that do not exist and code that does not compile are the two most common reasons an otherwise decent draft gets rejected. Our full position is in Editorial Standards.

Most rejections fall into one of these:

• Previously published somewhere else
• Thinly rewritten from an existing article
• A product pitch with a how-to wrapper
• Unsourced statistics or invented benchmarks
• Code that does not run
• Generic content with no specific experience behind it
• More links to your own site than the article can justify
• Off-topic for a technical audience

We tell you which one it was. A rejection is not a ban: most rejected drafts are accepted after a revision.

Run through this and you will clear review the first time far more often:

• It has not been published anywhere else
• Every factual claim has a source or a stated method
• All code has been run
• Links to your own site: two or fewer, each earning its place
• Images are yours or licensed, with alt text and no secrets in screenshots
• Headings are properly nested
• Any conflict of interest is disclosed
• You have read it once out loud

Editorial review takes up to 3 business days. You will get one of three outcomes: accepted, accepted with edits, or returned with the specific reason.

We may edit for grammar, clarity, formatting and headline. We will not change your argument or your conclusions without asking you first.

Questions about a specific draft? Contact the editorial team.