Write the Benefit, Not the Feature: Rewriting App Copy from Scratch

I wrote the first store description for Vakti Geçmeden myself. Its opening sentence was roughly this: “A food waste prevention platform running on location-based filtering and real-time stock synchronization.”

Technically accurate. It describes exactly what the app does. And nobody who reads that sentence downloads the app.

The problem was this: as the person who wrote the app, I knew it through its components. The person downloading it did not care about the components; they wondered what it would change in their life. I replaced that sentence with this one: “Buy what's left at the end of the day from nearby bakeries and grocery stores at half price.”

Same app, same features. Different sentence.

Why developers write features

This is not a lack of skill, it is a matter of perspective. You have spent months building a system, and to you the most remarkable part of it is the part that was hard to solve. Keeping real-time synchronization alive was hard, so that is what you want to write about.

To the user, the fact that synchronization was hard means nothing. What they care about is that the item they see is actually there. In other words, the thing you call “hard work” is, for the user, just an assumption that “it should work.”

A conversion table

Examples taken from my own apps. The left column is what I wrote first, the right column is what I replaced it with:

Notice what the sentences in the right column have in common: they all make the user the subject, and most of them point to a concrete moment — on the subway, within walking distance, until the job is done. An abstract benefit (“easier,” “faster”) is almost as ineffective as a feature.

Order matters in a store description

On a store page the user does not read the whole description. The first two or three lines are visible, the rest sits behind “read more.” So the first sentence of the description is the part of the whole text that deserves the most effort.

The order I use is this:

• Sentence 1: What the user gains, in a single sentence, with no technical terms.
• Sentence 2: Who it is for — a sentence that makes the audience clear. Something for everyone is for no one.
• Next block: How it works, in three steps.
• After that: The feature list. Yes, you can write features here — because anyone who has read this far is already convinced and is looking for detail.

So feature language is not forbidden; it just does not belong at the very top. What convinces someone who is not interested is a benefit; what makes an interested person decide is the detail.

In-app copy: the most neglected place

Putting effort into the store copy and leaving the in-app copy untouched is very common. Yet the sentences the user actually reads are in the app. Three places matter most:

Empty states. What the user sees the first time they open the app is usually an empty list. Saying “No records yet” tells them something is missing but not what to do about it. Instead you should write what they can do: “Turn on your location to see the businesses near you.” And put the button that performs that action right next to it.

Error messages. As a developer, the pull toward writing the error in the system's own language is strong. “Request failed (code: 503)” tells the user nothing. The questions the user needs answered are: is this my fault, what should I do, should I try again? “Couldn't connect. Check your internet and try again.” — that answers all three.

Button labels. Write the action instead of generic words like “OK,” “Send,” “Confirm.” In a confirmation dialog, the difference between “OK” and “Cancel the order” is the difference in regret the user feels when they tap it by mistake.

What I do after writing

There are two checks I run once the copy is written. The first is to have someone who has never seen the app read the sentence and ask them, “what do you think this is for?” If I end up having to explain, the sentence does not work.

The second is more brutal: I take my own sentence and swap the product name in it for the name of another app. If the sentence still makes sense, it is saying nothing about my product. “Its user-friendly interface makes your life easier” is true of every app — which means it is true of none of them.

Writing copy looks like a job outside of development. But copy is the first thing the product meets people with: the user reads the sentence first, then opens the app. How good the code is only starts to matter if that sentence managed to get them in the door.

• Marketing
• Content
• UX
• Product