Skip to content
iOS

A Stranger Left Three Stars and I Read It Like a Verdict

When to ask for App Store ratings, how to reply to reviews without sounding corporate, and what solo founders should measure beyond the average star count.

Iryna - Product designer & consumer app founderBy Iryna27 min read
Solo founder on a home terrace with iPhone showing App Store reviews, laptop and monitor with analytics nearby, and lake valley in the background

Listen to this article

26:01

AI-generated podcast-style overview of this article (not a word-for-word narration).

The notification was not from a friend. It was App Store Connect telling me someone left a three-star review on Finish Him Replies. Three stars is not a disaster. Three stars still stings when you have been staring at your own onboarding copy for two weeks and you know exactly which permission screen they probably hit before they ever pasted a reply.

I opened the review on my phone like it was a text I was afraid to read. The writer said the suggestions were "fine" but the app felt "pushy" about subscriptions. That word, pushy, sat with me longer than a one-star rant would have. They were not calling me a scammer. They were describing a feeling. Feelings are what consumer apps sell or lose in the first minute, and now that feeling was pinned under my app name for every stranger to browse.

That is the part the build tutorials skip. You can pass App Store review, polish your listing, and still discover that public opinion is a separate product surface you never designed. App store ratings reviews solo founder work is not vanity metrics homework. It is trust infrastructure: when to ask for stars, how to answer without sounding like a bank, and how to read velocity so you do not mistake a launch-week spike for a healthy reputation.

I am Iryna. I design consumer products and shipped one iOS app, Finish Him Replies, where the whole point is helping someone feel less stuck in an awkward text thread. I do not have a community manager, a Zendesk team, or a growth squad A/B testing review prompts. I have the same SKStoreReviewController API everyone else has, a support email I check between design files, and the uncomfortable truth that my average rating will never matter as much as what the latest one-star review says out loud. If you are still wiring the first session, start with how to build your first consumer iOS app and iOS onboarding. This piece assumes strangers can reach value. The question is whether they leave stars, and what you do when they do not.

One framing before we go section by section: ratings and review replies are not a growth hack you staple on after launch. They are the public echo of every decision you already made about permissions, paywall timing, empty states, and how you talk to people when something breaks. Get those right and the stars become easier to earn. Ignore them and no reply template saves you.

App store ratings reviews solo founder: what stars actually buy you

Stars are not a trophy. They are shorthand for strangers who will never DM you. When someone is standing in line comparing two screenshot-to-reply apps, or two habit trackers, or two journaling tools with similar icons, they scroll reviews the way they scroll comments on a restaurant listing. Not every word. The shape of the story. Recent pain. Recent praise. Whether the developer sounds alive.

For a solo founder, that is both unfair and useful. Unfair because one angry Tuesday can sit at the top of your page for months. Useful because a calm, specific reply is free marketing that compounds. You are not buying credibility with a billboard. You are earning it in public, one interaction at a time, with the same voice you used when you wrote the onboarding line that almost worked.

I think about stars buying three things: discovery, conversion, and emotional permission. Discovery is the ASO layer. Apple indexes review text more than founders appreciate, and fresh reviews signal that the app still exists in the world. Conversion is the shopper standing on your product page wondering if the one-star review about crashes is old news or this week's truth. Emotional permission is subtler. It is the user inside your app deciding whether you feel like a person who respects their awkward moment or a funnel hunting a five-star badge.

None of that replaces product quality. A perfect rating prompt cannot fix retention if the first session felt creepy. But ignoring ratings is also a mistake solo founders make because the numbers feel small early on. Twelve reviews. Eighteen reviews. You tell yourself you will "focus on product first" and deal with reputation later. Later is already happening in public while you refactor a button.

I used to think stars were something you "got" after the real work. Now I think they are part of the real work, especially for consumer iOS where the buyer is alone, slightly skeptical, and comparing you to three similar icons in search results. Your reply under a two-star review is as much product design as your empty state. It tells the next person whether you are still shipping, still listening, still the kind of developer who understands why someone felt vulnerable opening your app in the first place.

What Apple actually shows shoppers

The App Store product page is a compressed argument. Screenshots promise an outcome. The subtitle and description frame the category. Ratings sit in the header like a grade on the door. Tap through and you see the histogram, the written reviews, and the developer responses attached like little footnotes. Most users will not read fifty of them. They will read the newest one that matches their fear.

That is why app store ratings reviews solo founder strategy starts with honesty about placement. You do not control sort order completely. You do not control whether a reviewer mentions your price. You do control whether you answered the last three complaints with copy-paste corporate nothingness. Shoppers notice tone faster than feature lists.

Apple also limits how often the in-app rating prompt can appear per user per year. That constraint is a gift disguised as a restriction. It forces you to treat the ask like a scarce moment instead of a pop-up ad you spam until someone taps a star out of irritation. The founders who complain about "Apple won't let me ask more" are often trying to substitute volume for timing. Timing is the whole game on iOS.

Stars are lagging indicators wearing a leading costume

A jump from 4.1 to 4.6 feels like progress. Sometimes it is. Sometimes it means you finally stopped annoying power users with a mistimed paywall while the underlying one-session bounce rate is unchanged. I have learned to pair star movement with one product question: did the people leaving reviews this month actually reach the core win?

If your reviews praise the reply quality but mention confusion about photo access, you have a permissions copy problem, not a ratings problem. If reviews say "great idea" but never describe what they did inside the app, you might be harvesting warm installs who never activated. Stars decorate the storefront. Activation pays the rent.

Why a five-star ask on day one backfires

Timeline showing day-one rating prompt crossed out versus first-win and later-session timing for in-app review requests

I wanted validation the way anyone wants validation after months of building alone. The fantasy is easy: user installs, user loves it, user rates five stars, the algorithm notices, downloads compound, you sleep. So you put a rating request on the second screen, or right after the splash animation, or immediately after the first tap because you read a blog post that said "strike while enthusiasm is high."

Enthusiasm on day one is thin ice. The user does not know you yet. They know what your screenshot promised and whether your first thirty seconds felt safe. Asking for a star before they have pasted a reply, saved a journal entry, or completed whatever your app exists to do is asking them to cosign a relationship that has not happened. Many will tap "Not Now" and feel mildly annoyed. Some will tap five stars to make the dialog disappear, which helps your histogram and hurts your soul because you know the praise is hollow.

Consumer apps fail this test more often than B2B tools because the emotional stakes are personal. Finish Him Replies is not asking someone to evaluate invoice software after a demo call. It is asking someone to rate a product that just offered to help with a private conversation. If the ask arrives before the help lands, you feel like the pushy friend who wants a favor before they listen.

There is also a practical iOS reality. Apple throttles review prompts. Waste your first impression on a user who still does not understand the interface and you may not get another chance for months. That is not a moral lesson. It is inventory management for a scarce dialog.

The "Not Now" feeling sticks longer than the star

Mobile users do not separate your product from your interruptions. They experience both as one brand. A mistimed rating ask becomes part of the story: this app wants something from me before it gave me something I needed. You can recover from that, but recovery costs more sessions than you think. Meanwhile the user who would have rated you after a genuine win may never feel generous again because you spent your ask on the wrong beat.

I see this in reviews that say "fine but naggy" or "good app, too many popups." Those writers are not always describing three separate modals. Sometimes they mean one mistimed moment that colored everything after. Designers feel the sequence as separate systems: onboarding, core loop, paywall, rating. Users feel one continuous vibe.

Launch week is the worst time to optimize for stars

Launch week brings warm traffic. Friends. Indie hacker threads. People who already like you as a human. Their five-star reviews can inflate your average while hiding whether strangers activate. I am not saying ignore your supporters. I am saying do not treat launch week ratings as product validation.

The more useful question during launch week is whether cold users complete the core action without you narrating over their shoulder on FaceTime. Fix that first. Let stars come from people who found relief without already trusting your face. That is slower. It is also the difference between a listing that converts browsers and a listing that only impresses people who were going to install anyway.

When to trigger the in-app rating prompt (and when to stay quiet)

Matrix comparing listing trust signals with product reality and when stars lag behind the actual experience

Apple gives you SKStoreReviewController.requestReview() and a set of rules about not being obnoxious. What they do not give you is a script. The script is product judgment: which moment in your app corresponds to gratitude?

For Finish Him Replies, the honest moment is after someone copies one of the three replies and the sheet dismisses back to their messages app. Not before they see the replies. Not while the model is still thinking. Not on return visit one if visit one ended in confusion. The user should feel, even for a second, that the app did the job the App Store screenshots advertised.

Your moment will differ. A photo editor might ask after export. A habit tracker after three logged days, not after the first empty checkbox. A meditation app after a completed session, not after a paywall. The pattern is consistent: value delivered, friction low, exit or pause natural.

Stay quiet when the session ended in failure. Crash, empty state, permission denied, paywall bounce, "something went wrong" toast. Asking then is like requesting a Yelp review while the food is still on fire. Stay quiet when the user is mid-flow and one-handed. Stay quiet when you just showed another modal five seconds ago. Modal stacking trains people to dismiss without reading, which is the opposite of thoughtful feedback.

A timing map I wish I had earlier

I sketched this after reading too many reviews that mentioned "popups." It is not a law. It is a discipline check before you wire the prompt.

MomentAsk for rating?Why
First launch, before core actionNoNo proof yet; you are borrowing trust
Core action completed successfullyMaybeOnly if the UI is calm and no other modal is open
User returns for second session and repeats core actionStrong yesHabit signal plus fresh gratitude
Right after paywall rejectionNoEmotion is mixed at best
After support-related error screenNoFix the pain first
After user shares or exports a result they care aboutStrong yesSocial proof inside their life just happened

The table is blunt on purpose. Solo founders do not have time for a twelve-step lifecycle map. You have one or two honest wins per app. Pick them.

Pre-prompt screens are optional and easy to overbuild

Some apps show a custom sheet first: "Enjoying the app?" with Yes / Not really. That can filter sentiment before the system dialog appears. It can also feel like another layer of nagging if your core loop is already emotionally delicate. I kept Finish Him lean: no custom pre-prompt, just the system dialog after copy. If I add a pre-prompt later, it will be because analytics show I am interrupting the wrong users, not because a growth blog said custom sheets convert better.

If you use a pre-prompt, write copy that sounds like you on a good day. Not "We value your feedback." More like "Did this save you a minute?" with a clear escape hatch. And if they tap Not really, route to email or an in-app feedback field instead of the App Store. Negative private feedback beats a public one-star written in frustration.

What worked on TestFlight before I trusted production timing

Before I wired the production prompt, I watched five TestFlight sessions with screen recording. I noted the second each tester smiled, exhaled, or said "oh that's good." That second was never slide two of onboarding. It was always after the awkward part resolved: screenshot in, replies out, copy, paste into Messages. If your TestFlight testers never reach that face, your rating prompt timing is not the experiment yet. Your first session is.

I also asked one blunt question after the session: "Would you recommend this to a friend right now?" Not "would you rate five stars." Recommendation is closer to the truth. People recommend when they feel helped, not when they feel cornered by a dialog.

Respect Apple's limits without treating them as enemies

You cannot programmatically force a review. You cannot offer incentives in exchange for stars. You should not link users directly to the write-review URL as a substitute for the API in ways that feel like a dark pattern. Read Apple's Human Interface Guidelines on ratings and act like a guest in someone's phone. The solo-founder advantage is that you actually know why your app exists. Use that to pick a moment that feels fair, not clever.

How I write App Store review replies that do not sound corporate

Before and after panels contrasting a stiff corporate App Store reply with a short human response and fix note

Developer responses are public. They sit under the review like a second layer of product copy. For years big companies used replies as legal deflection. "We are sorry for your experience. Please contact support@..." with no human breath. Solo founders can do better because we are the support team, the product team, and the person who wrote the permission string.

My rule is simple: write like you are answering one tired human who might not be wrong, in front of an audience of future customers who are deciding if you are still paying attention.

Start with the feeling, not the facts. If someone says the app felt pushy, I do not open with "Our subscription model complies with App Store guidelines." I open with something closer to "That pushy feeling is not what I want, especially in a private moment." Facts come second: what changed, what they can try today, where to reach me if the issue is account-specific.

Keep it short. Three to six sentences is usually enough. Long replies read like you are litigating. The reviewer may never see your answer. The shopper scrolling next month will read the first two lines and decide if you sound human.

Name fixes when you have them. "We tightened the paywall copy in version 1.4 so free tries are clearer" is better than "We take feedback seriously." Specificity signals motion. Vague gratitude signals a template.

Thank five-star reviews without performing. "Glad this helped with a tricky thread" beats "We are thrilled you are enjoying our innovative platform." Innovation is a word strangers do not use about texting help. Relief is.

A reply shape that survives copy-paste temptation

I keep a note with three skeletons, not three identical messages. Negative functional issue: empathy, status of fix, workaround if any, support email. Negative vibe issue: empathy, product intent, what I changed or am testing, invitation to retry. Positive specific praise: mirror their words, mention one thing I am still improving, no upsell.

For the three-star "pushy" review on Finish Him, a good reply might sound like: "Thank you for saying this plainly. The app should feel like help, not a sales pitch in a vulnerable moment. I moved the subscription mention later and clarified how many free replies you get before any paywall appears. If you are open to trying again on the latest version, I would love to know if it still feels pushy. You can also reach me at support@ if something specific blocked you."

That reply does three jobs. It validates the feeling. It states a product change without being defensive. It gives a next step for someone who might update. Future readers see a founder who reads.

What I refuse to do in public replies

I do not argue star counts. I do not quote guidelines at users. I do not reveal private account details. I do not promise roadmaps I cannot ship in the next month. I do not insult reviewers, even when they misread the product. Some reviews are unfair. Public grace still costs less than public snark.

If a review is abusive or clearly spam, I report it through App Store Connect and move on. If it is wrong on facts, I correct gently: "The app does not store your screenshots after processing" with a link to the privacy policy, not "You did not read the FAQ."

Negative reviews are public support tickets

Flowchart for responding to negative reviews: read, reproduce, reply publicly, fix in app, and follow up

A one-star review is a support ticket pinned to your storefront. That sounds dramatic until you realize how many shoppers treat it exactly that way. They are not asking "Is this app mathematically a 1.0 out of 5?" They are asking "Will I be the next person who wastes time on a broken paywall?"

That reframing changed how I prioritize responses. Internal support email gets answered because it is polite. Public negative reviews get answered because they are sales infrastructure. Not every ticket needs a novel. Every ticket needs proof you are in the room.

The best public support replies do three things: acknowledge the pain without groveling, explain what is true about the product today, and offer a path that is not a trap. "Email me and I will fix it" only works if you actually check that inbox. An auto-reply graveyard is worse than silence.

Sometimes the fix is education. A reviewer angry about photo access might not have seen the one-line explanation before the picker. Your reply can restate that context for the next reader without scolding the original writer. Sometimes the fix is engineering. If two reviews mention the same crash, you are not in reputation management anymore. You are in incident response.

I keep a simple rule for respond to negative app review nights: sleep before you reply if the review made you angry. Not because the reviewer deserves patience. Because future shoppers read tone, and midnight tone is rarely the tone you want archived under your app name. Draft in Notes if you need to vent. Publish in the morning with coffee and version numbers.

There is also a category of negative review that is really a mismatch: someone wanted a different product than you built. A person who wanted a full dating coach downloaded a reply helper. You cannot argue them into satisfaction. You can clarify who the app is for so the next mismatched buyer self-selects out before leaving a star. That sounds harsh. It is kinder than another one-star from someone who never wanted your slice of the problem.

Turn one-star energy into private signal

When a negative review includes a specific bug, I copy the details into my bug list with the review date and app version. When it is vague ("does not work"), I reply asking for one detail I can reproduce: device model, iOS version, which screen. Many will not answer. Some will, and those answers are gold. You are not begging for a star change. You are debugging with the only user willing to talk in public.

I also watch for emotional categories that are not bugs. "Creepy." "Sketchy." "Too expensive for what it did." Those are product design tickets wearing review clothes. Fix the copy, the paywall timing, the empty state, the permission rationale. Replying helps. Shipping helps more.

When to ask Apple to remove a review

Rare. Use it for spam, hate, or reviews that clearly target the wrong app. Do not use it because someone criticized your business model. Apple is not your feelings manager. Legitimate negative reviews stay. Your job is to make the next version earn a better story.

Ratings velocity beats one launch-week spike

Line chart comparing a launch-week ratings spike with steady ratings velocity over following weeks

App store ratings velocity is the part indie founders ignore because it is less satisfying than a launch spike screenshot. Velocity means you keep earning new ratings and reviews week after week, not that you collected forty stars in seventy-two hours and then silence for six months.

Shoppers notice freshness even if they cannot define the word. A product page with a 4.7 average and twelve reviews from 2024 feels abandoned compared to a 4.4 with steady new comments this month. ASO is not only keywords in your subtitle. It is proof of ongoing life.

Launch week spikes are emotionally loud and strategically thin. Your friends rate you. Your Discord rates you. A Product Hunt bump might rate you. The histogram greens up. You feel legitimate. Then organic traffic arrives and sees three detailed complaints from strangers mixed among generic praise. Velocity was never there. You had a fireworks show, not a heartbeat.

Solo founders win by building a slow habit: after real wins, ask; after meaningful updates, mention in release notes that feedback helps; after fixing a painful bug, thank reviewers who reported it and invite others to retry. You are not gaming the store. You are keeping the public record aligned with the product you actually ship now.

I think about velocity the way I think about consumer app retention: not one heroic day, but whether the pattern repeats. A user who rates once after a win is nice. A user who returns next week, uses the app again, and still does not hate you is the person more likely to leave a written review when you finally ask at the right beat. Velocity is downstream of habit. Begging for stars without habit is noise.

Another solo-founder trap: comparing your review count to a category leader with years of updates and a marketing budget. Their velocity story includes press, ads, and brand searches you do not have yet. Compare your month to your previous month. Did new reviews arrive? Did themes change after a release? That is the scoreboard you can actually steer.

Think in months, not days

I set a boring personal target: at least a few new written reviews per month once organic usage exists. Not because the number is magic. Because zero new public signal for a quarter tells a story I do not want told. If usage is real but reviews are quiet, my prompt timing is probably wrong or my core loop is not reaching gratitude moments often enough.

Compare your review dates in App Store Connect the way you compare retention cohorts. A gap tells you something. Maybe you stopped shipping. Maybe you broke activation. Maybe you are asking at the wrong beat and users tap Not Now forever.

Rendering diagram…

The diagram is not automation. It is a reminder that velocity comes from repeated honest wins, not from one desperate launch-week blast.

What to measure besides your average star count

Average rating is a single number smoothing hundreds of different stories. It is useful for mood. It is weak for diagnosis. I track a small set of companion metrics so I know whether stars are celebrating health or decorating rot.

First, prompt exposure and outcome. If your analytics can log when you call the review API and when a review appears within a reasonable window, you learn whether your timing works. Low conversion after prompts means the moment is wrong or the product did not earn gratitude. High conversion with falling retention means you might be harvesting happy power users while strangers bounce silently.

Second, review recency and volume. Count how many reviews arrived in the last thirty, sixty, ninety days. Plot it in a spreadsheet if you have to. App Store Connect does not always make this obvious at a glance. You want a line that moves, not a cliff.

Third, theme frequency in text. I tag one- and two-star reviews by noun: paywall, crash, permissions, price, speed, misunderstanding. Two stars mentioning "permissions" is a pattern. One mention is anecdote. This is the same discipline as reading support email, except the inbox is public.

Fourth, version alignment. Note which app version the reviewer likely used if they mention UI that changed. It saves you from replying to ghost problems and helps you see whether your last release actually fixed the complaint.

Fifth, tie ratings to activation and retention from App Store Connect. If Day 1 retention is weak, do not expect stars to save you. If retention is healthy but ratings are stale, your ask timing or review volume is the bottleneck. The metrics talk to each other if you let them sit in the same note.

The vanity trap of chasing 4.8

A founder I know delayed shipping a necessary paywall change because they were afraid of a temporary rating dip. The dip came anyway when strangers hit the old confusing flow. Waiting made the reviews angrier and the fix later. Your goal is not a perfect histogram. Your goal is a product story that matches reality and improves in public.

Watch for average rating rising while written reviews complain about the same issue. That can happen when happy users rate quietly and unhappy users write paragraphs. The number lies gently. The text does not.

Pair ratings work with ASO and retention fixes

Ratings are not a separate growth channel you bolt on after "real work." They are the visible surface of onboarding, paywall, permissions, speed, and support. If you optimize prompts while ignoring consumer app retention, you are polishing a receipt for a meal people did not finish.

Start with the first session. Did the user reach the core win without account walls, confusing copy, or permission prompts that feel predatory? Fix that before you ask for stars. A beautiful ASO listing brings browsers. Retention decides whether they had something worth rating. Ratings decide whether the next browser believes them.

Then align listing copy with review language. If five-star reviews say "fast replies," your subtitle should not pretend you are a full relationship coach. If complaints mention price, your screenshots should show what free includes before the paywall. Consistency reduces one-star surprises from mismatched expectations.

Release notes are underrated reputation tools. When you fix a pain reviewers named, say so plainly. "Clearer photo permission explanation" is a signal to past critics and future shoppers. You are not groveling. You are showing motion.

Support email, in-app feedback, and public replies should tell the same story about privacy and pricing. Contradictions become reviews. Finish Him lives or dies on whether people trust us with a screenshot of a private chat. Every surface, including how I answer a two-star review about data, is part of that trust stack.

When I run an ask for app rating ios pass after a release, I do it in the same week I re-read my ASO screenshots and subtitle. If the store promises "three reply tones in seconds" and reviews keep saying "slow," I fix speed or soften the promise before I ask anyone to cosign the listing. Ratings amplify the story your product page already tells. Make sure that story is true this month, not true in your head during beta.

I also batch small reputation chores on Sunday evenings: reply to unanswered reviews, tag themes, check whether this week's support emails match what reviewers said publicly. Twenty minutes. Not heroic. Just enough that Monday morning does not start with dread about the storefront you forgot to tend.

Close the loop when you ship a fix

When a negative review names a bug you fixed, reply to the old review with an update and consider whether your release notes quote the change. Some founders DM reviewers through support if they left contact info. I do not ask anyone to change stars. I invite them to retry. If they update the review, great. If not, future readers still see I responded like a person shipping software, not hiding behind a brand.

Questions solo founders ask about App Store ratings

When should a solo founder ask for an App Store rating?

After the user has completed a meaningful win, not on first launch. For consumer apps, that usually means they copied a result, saved something they care about, or returned for a second session. Apple limits how often the system prompt can appear, so timing is a product decision, not a nagging schedule. If you cannot name the exact moment someone would feel grateful, you are not ready to ask.

Should I reply to every App Store review as a solo founder?

Reply to reviews that teach you something, reviews that misstate how the app works, and reviews where a calm human response would help the next reader. You do not need a corporate voice for five-star praise. A short thank-you is enough. Negative reviews deserve more care because they are public support tickets. Silence on a one-star rant that names a real bug looks like you disappeared.

How do I respond to a negative app review without making it worse?

Lead with empathy, name the fix or workaround if one exists, and invite the reviewer to contact support through a channel you actually monitor. Do not argue in public, do not copy-paste legal language, and do not promise a feature you will not ship. Readers judge your tone as much as the angry reviewer does. A gracious reply can turn a one-star wall into proof you are still in the room.

What is app store ratings velocity and why does it matter?

Velocity is how steadily you earn new ratings over time, not how many stars you collected during launch week. Apple and shoppers both notice freshness. A listing frozen at twelve reviews from month one looks abandoned even if the average is 4.8. A slower trickle of recent reviews signals an app people still use. Solo founders win by building a habit of earning reviews after real wins, not by begging everyone on day three.

Can I ask friends and family to rate my app?

Warm ratings help your feelings, not always your discovery. Apple discourages incentivized or misleading review campaigns, and readers can smell a launch-week cluster that does not match organic usage. A few honest reviews from people who used the app on their own phone are fine. A burst of generic five-star praise with no detail does not help ASO and can make you complacent about real product gaps.

What should I track besides my average star rating?

Track rating prompt show rate, review conversion after prompts, recent review count per month, sentiment themes in one- and two-star text, and whether negative reviews mention the same bug twice. Pair that with retention and activation from App Store Connect so you know if stars are lagging indicators of a first-session problem. Average rating is a mood ring. Patterns are diagnostics.

The star is not the whole conversation

I still feel a flutter when a new review notification arrives. I suspect I always will. Building alone makes every public opinion feel louder than it is. But I have stopped treating each star as a grade on my worth and started treating the whole review page as a product surface: when to ask, how to answer, what the text says about the version shipping today.

The three-star "pushy" review did not ruin Finish Him. It pointed at a paywall beat I had rushed because I was scared of revenue. I moved the ask. I clarified free tries. I replied like a human. The histogram moved slowly, which is the point. App store ratings reviews solo founder work is a long conversation in public, not a launch-week trophy.

If you take one thing from this: ask after gratitude, reply like you are still in the room, and read the words under the stars before you celebrate the average. The next stranger installing your app will read them before they ever open your onboarding. You might as well make that story true.

Share

Comments