How a solo builder handled every piece of communication: crafting questions, shaping responses, explaining features, writing copy, and learning when the message itself is the product.
Part of the ForkIt! Case Study. Read the full story →
Communications is not "writing copy." It is every touchpoint where someone forms an impression: the app store listing, the onboarding tour, the error message, the Reddit post asking for feedback, the privacy policy, the one-line pitch at a dinner table.
The first Reddit post got 110 upvotes, 54 comments, and 20K views. The one-sentence pitch: "Does just one thing: picks a restaurant within set filters."
That framing worked because it led with the problem, not the features. It did not say "check out my app." It said "I go to the same three places all the time, so I built something." The responses were specific and actionable because the framing invited stories, not wishlists.
110 upvotes is not a vanity metric. It is a signal that the framing resonated. The message was clear enough that people forwarded it to friends who had the same problem.
The quality of the answer depends entirely on the quality of the question. A vague ask produces vague feedback. A leading question confirms what you already believe. The craft is formulating questions that surface what people actually experience, not what they think you want to hear.
Swipe or use arrows
Every feature needs to be explained. The challenge is not having something to say. It is figuring out how to say it so someone who has never seen your app understands in five seconds.
The app needed a tagline. Something that explains what it does and why it exists in a single breath.
First attempts were descriptive: "A random restaurant picker that helps groups decide where to eat." Accurate. Forgettable.
Variations included: "Stop arguing about dinner." "Let the app decide." "Random restaurants, no regrets."
Each one explained what the app does. None of them created a reaction.
The test: say it to someone at a dinner table and see if they smile, nod, or ask a follow-up question.
"Fork Around. Find Out."
Every single person laughed. Then asked what it does. That is the entire job of a one-liner: make someone curious enough to ask.
The name itself was a journey. "ForkIt!" couldn't be purchased as a domain. Trademark research turned up other companies in the space. "ForkFate" was the first rebrand attempt, and it never felt right. "Fork Around" worked because the language does triple duty: a round of drinks, send the poll around, fork around and find out. The .io domain was available. The trademark was clear.
From the Reddit thread: "I just wanted an excuse to almost say FuckIt all the time." Authentic voice is a comms strategy, even when (especially when) it sounds like it is not.
Store listings have brutal constraints. The subtitle is 30 characters. The first line of the description is all most people read.
The subtitle: "Random Restaurant Picker." Four words. No adjectives. No marketing language. Just what it does.
The writing process for all copy: draft it raw, let Claude smooth out the aggressive personality, then put a little charm back in. Three passes. The first has the voice; the second has the polish; the third has both.
Version 1 of the info modal was a wall of text. Feature descriptions, legal links, version notes, all in one scrollable block.
The builder stopped reading it during her own testing. In her words: "If I stopped, I know the users would." If the person who wrote it won't finish reading it, users definitely won't.
The communication failed not because the content was wrong, but because the format was wrong.
The fix: break it into scannable sections with uppercase labels (ACCOUNT, SUBSCRIPTION, ABOUT). Each section is a self-contained answer to one question.
Users went from scrolling past everything to tapping directly into the section they needed.
The content did not change. The communication did.
Some features exist entirely to communicate. The onboarding tour is not a feature. It is a conversation with a first-time user. The privacy policy is not a legal document. It is a trust signal. "No ads, no tracking" is not a setting. It is a brand promise.
The original onboarding was a single screen of text explaining every feature. Users dismissed it instantly. Zero retention of what the app could do.
The replacement: a 12-step interactive spotlight tour. Each step highlights one element, explains it in one sentence, and lets the user tap Next. Back button for review. Replayable from the info modal.
The tour is not documentation. It is a guided conversation: "Here is what this does. Here is why you care. Ready for the next thing?"
Completion rate went from near-zero (wall of text) to the majority of first-time users finishing all 12 steps.
Is a privacy policy a comms document or a legal checkbox? Honest answer: "I don't know." But the decision was to write it like the former and hope it also covers the latter.
The core message: we collect your location to find restaurants near you. We do not store it, sell it, or track you. That is it.
When users can understand what you do with their data in one sentence, the policy becomes a trust signal instead of a legal obligation.
Trust is a comms outcome, not a legal one.
Multiple Reddit users wanted iOS. The typical response would be "coming soon" or "it's on the roadmap." Instead, the response was building a web app that afternoon and posting the link back in the thread.
The actual reply: "I built a web app version of it this afternoon to hold y'all over :)"
This is communication through action. The message was not "we hear you." The message was the deliverable itself. Users did not need to trust a promise; they could open a browser and use the thing.
Sometimes the most effective message is not words. It is shipping.
This started as a personal preference: ads are annoying and tracking is invasive. But saying it out loud turned it into a differentiator.
When restaurant owners asked about buying ad space, the answer was immediate: no. When a friend warned about the "Yelp 2.0 path," the response was already decided.
The principle is not just a policy. It is the answer to the question every user implicitly asks: "Who pays the bills, and what does that mean for me?"
The stated message is "no ads." The real message is "you are the user, not the product."
The first version of the info modal put every piece of information in a single scrollable view. Version history, feature explanations, legal links, subscription details, all in one place.
The assumption was: if all the information is there, users will find what they need. The reality was: nobody scrolled past the first three lines.
Cost: Users did not know the app had features they would have used. The "Take a Tour" button was buried. Subscription details were invisible.
Lesson: availability is not the same as accessibility. Information that exists but cannot be found has not been communicated.
Early Reddit posts were structured as announcements: "I built a restaurant picker app! Check it out!" The responses were polite and encouraging — but not actionable. "Looks cool!" "Nice work!" Nothing to build from.
The framing invited praise, not critique. People respond to the structure of the ask. If the ask sounds like "tell me this is good," that is what you get.
Cost: Weeks of iteration guided by silence instead of signal. Features that seemed fine because no one pointed out problems (because no one was asked the right way).
Lesson: "What do you think?" is not a feedback question. "What would stop you from using this?" is.
In early demos, the pitch was a feature list: "It has filters, it picks random restaurants, it shows ratings, it has a radius selector."
Eyes glazed. Nobody cared about the radius selector. What they cared about was: "Will this actually end the argument about where to eat?"
Cost: Lost the first 30 seconds of every demo, which is when attention is highest.
Lesson: lead with the problem, not the solution. "You know when nobody can agree on dinner?" gets a nod. A feature list gets a polite smile.
Practical templates extracted from what worked (and what failed). Each one is a repeatable pattern.
Hover over (or click) a card to see the example in action.
1. Lead with your problem, not your product ("I go to the same three places"). 2. Describe what you built in one sentence ("does one thing"). 3. Invite action, not opinions ("lmk if you want to join"). No feature list, no technical details.
1. Name the problem in the user's words. 2. State what the feature does (not how). 3. One sentence max. If it takes two, the feature is too complex or the explanation is.
1. Say it out loud at a dinner table. 2. If nobody reacts, it is too descriptive. 3. If someone laughs or asks a question, keep it. 4. Clever only works if it is also clear.
1. State the principle as a fact, not a selling point. 2. Explain what it means for the user. 3. Back it up with a decision you made because of it.
Communications is not a talent or a department. It is a discipline: say what you mean, say it clearly, and say it where people will actually encounter it.
Every feature explanation, every feedback question, every store listing, every error message is a piece of communication. The only question is whether it was written with intention or left to chance.
Good comms is not about being articulate. It is about being clear. If someone has to ask what you meant, the communication failed, no matter how well it was written.
Quotes from real stakeholder conversations. Names are Reddit usernames; emails redacted.