MC-Guide
Content Writing
Website 111: plainenglish.io
How Can You Earn Money Writing For “plainenglish.io” Website
This guide shows you, step by step, how a beginner can learn to pitch and sell stories to plainenglish.io.
You will learn what plainenglish.io wants, how to test your idea, how to write a pitch, and how payment roughly works. You can use this like a small SOP.
Guide: How to Write for PlainEnglish.io (Step by Step) — and Turn Your Byline into Income
This is a beginner-first guide to help you publish on PlainEnglish.io and use that publishing experience to earn money through real-world outcomes: paid writing opportunities inside their community, freelance clients, better job interviews, and a stronger portfolio.
You will learn how the platform works, what they accept, how to choose topics, how to write in a clean “plain English” style, how to submit correctly, and how to build a simple money plan from your published work. You can treat this like an SOP.
Important reality check: Plain English says they do not pay writers for publishing content. Publishing is a voluntary project. They mention paid writing opportunities are offered via their community, and selection is based on proficiency and quality contributions. (We use this fact in the monetization plan below.)
Section 1 · Understand the platform
What PlainEnglish.io actually is (and why it’s useful for earning)
PlainEnglish.io is a tech-focused media platform. It is connected to a network of well-known tech publications and communities. Their about page says the platform has had tens of thousands of writers, tens of thousands of articles, and millions of monthly views from many countries. That matters because your best path to income is often: visibility → trust → opportunities.
Think of Plain English as a “distribution + credibility engine”. You publish useful content, editors help improve it, your name is credited, and your article can bring traffic over time. Plain English says this can help you get hired, land a better opportunity, or pick up a new client.
- A real byline you can show to clients and employers.
- Editorial improvements that teach you professional standards.
- Search visibility (your article can rank over time).
- A network effect: your work sits inside a bigger ecosystem.
- Community access (where paid opportunities are mentioned).
Even if you are not paid for publishing, a strong byline can generate income indirectly. This guide shows you the exact steps.
Plain English links to these network publications (use them to study topics and style):
- AI in Plain English
- AWS in Plain English
- JavaScript in Plain English
- Python in Plain English
- Stackademic
- Venture
- Cubed
- CoFeed
You do not need to publish everywhere. But you should read across the network to find what resonates.
| Where you publish | What it gives you | Beginner use |
|---|---|---|
| PlainEnglish.io | Editorial review + credibility + possible SEO traffic | Build portfolio + trust quickly |
| Network publications (AI/AWS/JS/Python/Stackademic) | Topic clarity + style examples + audience expectations | Study + get topic ideas |
| Newsletter + social distribution | Extra reach and community awareness | Learn how distribution works |
| Differ (free blog) | A place to host your own writing, samples, and experiments | Create practice posts and link as proof |
Section 2 · Pick your lane
Pick the right topic and the right “home” for your article
Beginners often fail here: they choose a topic that is too broad, too basic, or too promotional. Your goal is to pick a topic that creates a strong reaction in the reader: “I can use this today.”
Use the Plain English network as a map. If you are writing AI, study: AI in Plain English. If you are writing cloud, study: AWS in Plain English. If you are writing JavaScript, study: JavaScript in Plain English. If you are writing Python, study: Python in Plain English.
Write about a “real problem” — not a textbook definition
Bad topic: “What is Docker?”
Better topic: “Dockerizing a Node.js app with a clean dev/prod setup (with common mistakes fixed).”
Plain English publishes practical tech content. Your best advantage is to write from real experience: something you built, fixed, deployed, optimized, or debugged.
Make the angle specific in one sentence
Use this sentence: “This article helps [who] do [what] so they can [result].”
- This article helps junior devs deploy a FastAPI app so they can share a working demo.
- This article helps React devs reduce bundle size so they can improve performance.
- This article helps AWS learners set up IAM cleanly so they can stop getting AccessDenied errors.
Collect 3 “proof assets” before you write
- One screenshot (error, before/after, dashboard, output).
- One code sample you tested yourself.
- One measurable outcome (time saved, steps reduced, bug fixed, speed improved).
Proof assets make your article feel real. Editors trust it more. Readers love it.
| Publication lane | Good beginner topics | What to include |
|---|---|---|
| JavaScript in Plain English | Debugging, performance, patterns, clean APIs, tests | Snippets + small project + mistakes + fix |
| Python in Plain English | Automation, APIs, data tools, scraping ethics, deployment basics | Steps + outputs + “why this works” |
| AWS in Plain English | IAM basics, S3 patterns, Lambda workflows, cost traps | Architecture diagram + guardrails + checks |
| AI in Plain English | Prompt patterns, eval basics, simple apps, automation | Examples + failure cases + safety notes |
Section 3 · Beginner setup
Build a small base before you submit (so your acceptance rate goes up)
You do not need a huge portfolio. But you need signals. Signals tell editors: “This writer finishes things. This writer tests things. This writer cares.”
- Create a simple author bio: what you build, what you write about, who you help.
- Make one profile link you’re proud to share (LinkedIn or GitHub).
- Create a folder for screenshots and proof assets (before/after, outputs).
- Write a 150-word “about me” paragraph you can reuse everywhere.
Bonus: start your own practice blog on Differ so you can publish drafts and link to them as samples.
- Create one tiny project you can screenshot and explain.
- Save 3 screenshots: problem, process, final result.
- Save 3 code snippets: core function, config, final usage example.
- Write down 5 mistakes you made and how you fixed them.
Proof assets help you write faster and make your article feel real.
| Asset | Why editors like it | Beginner example |
|---|---|---|
| 1 small demo | Proves you tested the steps | Simple API + README + screenshot |
| Before/after screenshot | Makes the story concrete | Error screen → fixed output |
| Resource links | Shows responsibility and research | Official docs + references at bottom |
| Short author bio | Helps readers trust the writer | “I build X, I write about Y, I help Z” |
Section 4 · Editorial rules
What gets rejected (and how to avoid it as a beginner)
You can avoid most rejections with one mindset: be useful, be honest, and be clean. Plain English says their editorial team reviews content, fixes typos, and may make minor changes for quality and SEO. But they can reject content if it has too many mistakes, comprehension issues, poor quality, or irrelevant topics.
- Too many basic explanations with no real example or project.
- Generic AI-sounding writing (no proof, no story, no specifics).
- No structure (long paragraphs, no headings, no clear steps).
- Unverified code or “it should work” steps.
- Heavy promotion, affiliate links, or paid-product placement.
Fix: write like a helpful teammate, not like a marketer.
- You can add a CTA for a newsletter, a YouTube channel, or open-source software.
- If you want to promote a paid service/product/course, they ask you to contact them first.
- They say they will remove affiliate links and can reject articles with unapproved paid placements.
Use a clean CTA at the bottom. Keep it small. Make the article the main value.
Section 5 · Writing blueprint
The “Plain English” article blueprint (simple, clean, and trusted)
Plain English’s writing guidance pushes a simple idea: write articles people want to read, not articles that sound “smart”. That means: short paragraphs, clear headings, practical steps, and useful resources.
Here is a beginner blueprint you can reuse for blogs, magazine-style pieces, guest posts, or tutorials. You can publish it on your own blog too, not just Plain English.
| Section | What to write | Beginner tip |
|---|---|---|
| Hook (5–8 lines) | What problem this solves + who it is for | Start with the pain, not history |
| Outcome | What the reader will have at the end | One clear “after” statement |
| Prerequisites | Tools, versions, assumptions | Make it easy to follow |
| Steps (4–8) | Each step is small and testable | Show output after each step |
| Mistakes + fixes | Common errors you hit | This is where trust is built |
| Summary | What changed, what you learned | Repeat key points in bullets |
| Resources | Links to docs, references, tools | Put resources at bottom |
Write a hook that sounds like a helpful friend
Use this hook template: “If you are trying to [goal] but you keep hitting [problem], this guide will show you a clean fix.”
Example: “If you are trying to deploy a small API but you keep getting environment errors, this guide shows a clean setup that works in both local and production.”
No fancy words. No “In today’s world.” Just problem, reader, promise.
Use “micro paragraphs” (2–3 lines)
Long paragraphs are hard to scan. Beginners get lost. Keep paragraphs short. Use bullets when you list steps, tools, or rules.
- One idea per paragraph.
- Use headings every 200–300 words.
- Show outputs and screenshots.