DEV Community: Shweta Kumari

Copywriting vs Content Writing: What's the Difference, and Which One Do You Actually Need?

Shweta Kumari — Tue, 21 Jul 2026 06:40:42 +0000

A client asked me last month, "So are you a copywriter or a content writer?" I stopped for a moment because, to be honest, most people use "copywriter" and "content writer" in that way. They are not the same thing. And choosing the wrong one for the job is one of the most common mistakes that businesses make, and it can be very costly.
Here is how I would explain it without using definitions.

The Simple Way to Think About It

A copywriter is about making someone do something. Content writing is about making someone think or trust or learn something about copywriters and content writers.

A copywriter crafts the words on your website that encourage visitors to click "Buy" on your products or services. In contrast, a content writer produces articles that help build trust in your brand and prompt readers to consider using your services.

One tries to get someone to make a decision. The other helps build a relationship with a copywriter and content writer that makes it easier for someone to make a decision.

Where You'll See Each One

Copywriting shows up in:

Landing pages
Ads (Google, Facebook, Instagram)
Email subject lines and sales emails
Product descriptions
Sales pages, CTAs, taglines

Content writing shows up in:

Blog posts
LinkedIn posts (most of the time)
Newsletters that inform rather than sell
Guides, case studies, long-form articles

Website "About" pages, in most cases

If you're trying to sell something in the next five minutes, you need copy. If you're trying to build an audience that trusts you over the next five months, you need content.

Why This Matters More Than People Think

I have seen businesses hire a content writer to write their sales page. The page reads beautifully, but nobody buys from them. This is because the sales page was written to inform people not to convert them into buyers. There is a lack of urgency, no clear call to action, and no compelling reason for people to take action today and make a purchase from the business.

I have also seen the opposite thing happen. A business hires a copywriter to write their blog. Every post ends up sounding like an advertisement. The people who read the blog can feel that it is an advertisement, and they leave the website immediately. Nobody wants to read a sales pitch that is disguised as a blog post about something.

The difference between a sales page and a blog post is very subtle. It costs the business a lot of money. The business ends up with content that either does not convert people into buyers or does not build trust with the people who read it. Sometimes the content does not do either of these things, and that is a problem for the business and their sales page and blog.

So, Which One Do You Need?

Honestly, most businesses need both — just for different parts of their funnel.
If your problem is traffic and trust (people don't know you exist, or don't trust you enough yet) — you need content writing first.

If your problem is conversion (people are visiting your site or profile but not buying, booking, or signing up) — you need copywriting.

A quick way to check: read your own website or last five posts out loud. If it sounds like it's teaching or telling a story, that's content. If it sounds like it's asking for something — a click, a sale, a signup — that's a copy.

Summary

The best writers I know do not choose one thing. Stick to it. They like to mix things up. The best sales pages have a story in them. This is where content and copy overlap. The best blog posts still tell you what to do next. This is where copy and content come together again. The truth is, good writing does not always follow the rules.
If you are not sure what your business needs now. Content or copy. That is usually a sign that you need to figure it out before you spend any money on either content or copy.

How to Plan a Book Before You Write the First Chapter

Shweta Kumari — Sun, 05 Jul 2026 07:22:52 +0000

Every writer can recall the morning they popped open a new Word document, wrote “Chapter One," and stared at the screen for the next twenty minutes without typing another word. The struggle isn't due to a lack of words or solid ideas. I can recall my day clearly.

I had a good hook, but no plan.

Three weeks later, I had produced forty pages that I was dissatisfied with, a narrative that was progressing nowhere, and two characters who were uncertain about their purpose. I deleted almost everything and started over, this time with a plan. The choice had a profound impact. I won’t say writing gets easy, but it does become possible when the initial excitement fades, and all that’s left is the bleak prospect of making it to Tuesday.
If you’re currently faced with a brilliant idea that you don’t know where to take, read below for everything I wish that somebody had told me when I sat down to write that first chapter.

**Why "Just Start Writing" Doesn't Always Work

**
There's a popular idea that real writers just sit down and let the story pour out of them. For some people, that's true. For most of us, it's a fast way to burn out.

A book is not a short story. It's not something you can hold entirely in your head while you write it. Somewhere around chapter six or seven, you will forget a small detail, contradict something you said earlier, or realise your protagonist has no real reason to be doing what they're doing. Without a plan, these problems pile up quietly until the whole draft feels like it's held together with tape.

Planning isn't the opposite of creativity. It's what protects your creativity from collapsing under its own weight halfway through.

Start With the One-Sentence Idea

**
Before outlines, before character sheets, before anything else — you need to be able to say what your book is about in one sentence.

Not the plot. The idea underneath the plot.

**
A story about a woman who inherits her grandmother's bakery is a plot. A story about someone learning to forgive a parent she never really knew is an idea. The plot is what happens. The idea is why anyone should care.

If you can't answer this yet, that's fine. It's actually the most important question to sit with before you write anything else, because every planning decision after this point depends on the answer.

Know Your Ending Before You Know Your Middle

**
This one surprises people. You don't need to know every twist and turn of your book, but you do need to know, roughly, where it ends.

Think of your ending as a destination on a map. You don't need to know every street you'll take to get there, but if you don't know the destination, you can't tell if you're heading in the right direction at all. Writers who skip this step often find themselves 200 pages in with no clear sense of what they're building toward, and that uncertainty shows up on the page as meandering, repetitive scenes.

You can change the ending later. Most writers do. But write toward something, even if that something eventually changes.
Build Your Characters Before Your Chapters
A plan without real characters is just a sequence of events. Readers don't stay for what happens. They stay for whom it's happening to.

Before you plan a single chapter, sit with your main characters. What do they want? What are they afraid of? What do they believe about themselves that isn't true yet? A character who wants something and is afraid of something else is already halfway to being interesting before a single event happens to them.

This is also where a lot of plot problems solve themselves. If you're stuck on what should happen next in your outline, the answer is usually hiding in what your character wants and what's stopping them from getting it.
Outline Loosely, Not Rigidly

Here's where a lot of planning advice goes wrong. It tells you to map every scene down to the last detail, as if a book were a spreadsheet you fill in.

That kind of outline works for some writers and completely kills the story for others. What actually works for most people is a loose outline: a list of key turning points, not a scene-by-scene breakdown. Think of it as a trail of stepping stones across a river, not a paved road. You know where you're stepping next, but there's still room to walk a little differently each time.

A good outline should answer: what changes at the beginning, what changes in the middle, and what's different by the end. Everything else can be discovered while writing.
Do Just Enough Research, Not All of It

Research can be one of the most productive parts of planning a book — or one of the sneakiest ways to avoid writing it.

If your book needs specific knowledge, whether that's medical details, a historical period, or how a particular industry works, do enough research to write confidently, then stop. You don't need to become an expert before you write chapter one. You need to know enough not to make an obvious mistake, and enough to know what to look up later when you get there.

Write a Planning Document, Not Just Notes in Your Head

**
This is the step almost every unfinished book is missing. Not a formal outline necessarily, but something written down: your one-sentence idea, your ending, your characters' wants and fears, and your rough structure.

Ideas feel complete in your head. They rarely survive contact with the page unless you've written them down first. A short planning document, even one page, gives you something to return to on the days you sit down to write and can't remember why you were excited about this story in the first place.

The Real Reason Planning Matters

**
Planning a book isn't about control. It's about giving yourself something solid to hold onto on the days when writing feels hard, which will be most days.

The writers who finish books aren't always the most talented ones in the room. They're usually the ones who had a plan solid enough to keep going when the motivation ran out, which it always does, somewhere around the middle.

If you have an idea for a book and you're standing at the edge of it, unsure how to begin, start here. Not with chapter one. With the plan that will carry you there.

Why "I Can't Reproduce This" Is Still the Most Annoying Sentence in Software

Shweta Kumari — Tue, 23 Jun 2026 11:37:34 +0000

Been part of a dev team longer than a few months? You’ve experienced the cycle: The bug comes in the door. You open the ticket.

It says something to the effect of “the button doesn’t work” or "the page becomes stuck on occasion.”

No reproduction steps. No screenshot. I have no idea which browser, user profile, or specific actions the user took just before everything went wrong. So, you inquire about more info.

A day goes by, and you get a response.

You ask again: what do the browser’s developer tools say in the Console tab? Are there any failed network requests? Are you on Windows, Mac, or Linux? Which version? Another couple of days pass. Eventually, you have enough context to start actual debugging. Sometimes it resolves immediately, or somehow ‘fixes itself.’

This issue is systemic, not just an isolated incident or a minor inconvenience. Testers, support staff, and even other developers do not approach problems with the same understanding of stack traces. They generally work in a “This looks broken" mode, and frankly, they probably should work in that mode, because it’s not their job to know that that indicates a 500 Internal Server Error.

But it is your job to determine, not theirs.

The usual bug reporting tools don’t really close the gap. A screenshot shows you the moment something went wrong, but not the five steps that led there. A screen recording captures the what but not the why — no console logs, no failed network requests, nothing about device or browser state. And tools like Jira or Linear are great at tracking that a bug exists, but they were never built to actually collect the debugging context around it. You still end up pasting logs manually, if anyone even thought to grab them.

I’ve seen a couple of browser extensions try to address this gap over the years, and Brie.io is one browser extension for bug reports I’ve actually kept on my browser. It helps teams reproduce bugs without repeated back-and-forth. When something fails, I click it, and it records a screenshot or a few seconds of session replay alongside the browser's console logs, network activity, and basic device information into a bundle. (Nope, you’re not asking your users for the HAR file or copy-pasting inscrutable error messages).

The aspect I really appreciate is that it doesn't try to replace your issue tracker—instead, it ensures that the bug you finally submit to Jira or Linear is actually useful at the other end.

If your team is doing browser-based QA testing or you manage a support queue taking “it’s broken” emails from your non-technical colleagues, this becomes meaningful—you get a head start at resolving the problem instead of the first hour on a bug spent trying to get the reporter to reproduce the issue again. Certainly not a silver bullet, and you still get tricky ones that won't be captured that easily, but for many common "works on my machine" scenarios, being able to automatically send the session along has already saved our team a lot of back-and-forth while trying to reproduce bugs.