Every in-app message is an interruption the user did not agree to. That is a standard that needs to be met for the copy. It better be worth stopping what you’re doing for, otherwise why was it sent?
This means the writing brief involves both targeting and timing. The same sentence is useful for someone on day twelve but for someone after only two minutes it is frustrating.
Which makes targeting and timing part of the writing brief.
What Makes No-AI In-app Messages Easy to Understand?
A message that interrupts some important work needs to have a reason that is clear in about eight words. The easiest way to do this is to name the user’s action. Messages that begin with a product announcement typically get dismissed before the second line, and, in the process, the user also dismisses the next message.
Where AI falls down on in-app messages
A model writes each message as if it were the only one. You ask for ten, and ten different messages come back, each delivering optimism and cheer, as if your audience is an undivided and loyal focus group with no knowledge of your product. Together, the messages come off as a series of unwanted messages, and users block the channel, which marks a net negative for the campaign.
Product Context and Writing for No-AI In-app Messages
We always begin by addressing the trigger and not the message. The writer requires the information on the user’s activity for this interruption, their level of advancement within the product, and the anticipated outcome if the message is ignored. Messages that are sent without a trigger beyond a set launch date are either modified to new messages, or are ignored.
Keeping No-AI In-app Messages Consistent Across Your App
Message sets accumulate. After a year most products have twenty live messages written by six people, several firing at once for the same user. We document the triggers in one table beside the copy, which is the only reliable way to see the collisions and the moments where someone gets three interruptions in a minute.
What in-app messages cost
One rate, whatever the format: $10 per 100 words. You are paying for the writer’s time and judgement, so the price scales with the words rather than with a package tier.
Typical in-app message
Words
Writing
Fee (1%)
You pay
Short
500
$50
$0.50
$50.50
Standard
1,000
$100
$1
$101
In-depth
2,000
$200
$2
$202
The writer receives 100% of the writing price. Our 1% fee is added on top of it, and 0.5% is donated to tree planting.
Full pricing breakdown.
No-AI In-app Messages Product Writing FAQs
Ask on the contact page and a person will answer, usually the same working day. For a live order, reply to your confirmation email and it reaches whoever is handling it.
Ask on the contact page and a person will answer, usually the same working day. For a live order, reply to your confirmation email and it reaches whoever is handling it.
Yes, provide us with the character limits and what variables exist for us to include fallbacks for empty variables. Avoid checking in with a greeting that states ‘Hi there,’ as a first name is not provided. This is the most basic mistake one can make in this template.
In most cases, the useful test is per user and not per month. If a user can realistically see two interruptions in a session, one of those interruptions must be removed. We will tell you which one of the interruptions to remove based on the triggers before the set is written.
Completely. Copyright transfers to you on delivery, with no attribution requirement and no licence back to us. Nothing written for you is resold, repurposed or republished.
Reviews
What clients say about our in-app messages
Reviews from completed, paid orders in this category.
ATAna-Maria TImplementation Lead, Corvid Fleet
One prerequisite missing, otherwise ready
Ordering is clearly very good, and the screenshots are clearly explained. The guide assumes the customer has admin access, which a good number of them do not. We wrote a pre-req box ourselves in ten minutes. Everything else was complete.
Verified orderSetup guidesMarch 2026
ALAnders LEngineering Manager, Kestrel Systems
The error codes section alone
Our API documentation was written over an uneven four-year span. The author went through every single one and flagged six cases where our error responses were inconsistent with the description and raised them instead of just fixing them on the fly. That was worth the order.
Verified orderAPI documentationApril 2026
HJHenrik JCTO, Loomstack
Engineers read them now
Our release notes went unread, but they serve the purpose of listing what breaks and what doesn’t when considering whether to upgrade. Two customers actually took the time to send thank yous in the same week, something that had never happened before.