A welcome screen is twelve words plus a button, and a lot of work goes into it. This is because it is the only screen that your every single user sees, and is the only screen that has to work for someone that has absolutely no context for you.
Summarizing the product can often be done; however, it is better to show the user how to perform that one task that they are interested in.
The first screen sets the tone for everything that follows. Users interpret the language used to describe features and determine how rigidly they interpret the interface. If a first screen promises a particular outcome, users trust that the following interface will behave correspondingly. Users learn to skip decorative copy when the first screen consists of a greeting and a tagline. If you would rather your users pay attention to serious advisories, make sure that the first screen does not miss the opportunity to set the serious and cautious tone required to convey the warnings.
Make a suggestion for a welcome screen and you get ‘Welcome to AppName. Let us get you started.’ This generic welcome message is grammatical and true for all apps, like apps for banking and bird identification. This screen, which every single user will see, cannot be the work of everyone. Example text for the single purpose of illustrating formatting. This line should be at the very bottom of the submission. Example text for the single purpose of illustrating formatting. This line should be at the very bottom of the submission.
We save working on the welcome screens for last, after the rest of the first run. The reason for doing it this way is that we need to know what that screen has to accomplish for the rest of the first run. The writer has to make about fifteen drafts before the screen for the first run looks complete. The writer then reads that screen out loud to see if anything sounds like a press release. Anything that does gets kept. We then pair all of it with the most concise text on the screen.
A review requires three things to be all productive. A single draft, however, turns it into a debate of taste. We’ve provided three fully articulated screens that each take a different position and a description of what each assumes about your user. Your team picks a direction, and then the revisions can be used to progress that selection, rather than starting over.
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 welcome screen | 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.
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.
Often not. If your app can show something useful within two seconds, a welcome screen is a wall in front of it, and we will say so and write the alternative instead. When there is a genuine setup decision to make, the screen earns its place.
A splash screen should contain nothing other than a wait time. A welcome screen is entitled to ask for something and in fact should. A screen requiring load time to be instructions to focus on speeding up that time. This will be the better project and we’ll call it that too.
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 from completed, paid orders in this category.
Mostly excellent. Your improvements to the auth section are better than what our engineers wrote. Your pagination endpoints, however, were explained in the spec according to how they behave rather than how they are, which required two revisions. Our spec is incorrect in that area as well.
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.
Our releases happen every fortnight, and our notes have evolved into change logs. To keep things organized, the writer has noted what changed within a card or view and what changed underneath. Each note is a brief summary of the change. The biggest metric I’m interested in post release is the volume of support tickets. It always dips.
We do not ask you to take the no-AI promise on trust. Each draft is run through these platforms and the reports are attached to your delivery email.
Originality.aiAI detection + plagiarism
GPTZeroAI detection
TurnitinAI detection + similarity
CopyleaksAI detection + plagiarism
Winston AIAI detection
ZeroGPTAI detection
SaplingAI detection
Content at ScaleAI detection
Send the brief, get a human draft back within 3 days. No account, no subscription, no AI.
$10 per 100 words · all of it to the writer · 0.5% to trees