Communication

What communication apps are worth building?

The category is crowded with general inboxes and messengers, so a new idea needs a narrower job. Look for a message with a known structure and a known moment when it is needed: the reply to a complaint, the follow-up after a meeting, the opening line for one industry, or the notice that a booking is at risk. A tool built around one moment is easier to explain and easier to test than an all-purpose messenger.

Two families of idea show up on the board. Live assistants sit beside a conversation and suggest what to say next, as the cold-call idea does. Draft queues collect messages a person keeps postponing and produce replies that can be reviewed in one pass, as the email idea does. Both keep a person in the send step, which limits the damage a bad draft can do.

Who uses communication apps, and how do you reach them?

The buyer and the user are often different people. An individual with an email backlog will use a draft tool, but a manager pays for it only when team response times are a number they report on. Sales teams buy call tools after a manager sees a quota missed. Small service businesses buy a booking confirmer after a no-show has cost them an afternoon.

Reach these people in the channels where the pain is already discussed: sales and support communities, forums for the software that holds the messages, and creators who write about inbox habits. A free tool with an honest first use can spread without ads, because a user can show a colleague the result on their own message.

A quick test of demand is to ask five people to forward the last message they put off, then note how long it sat. If the wait is measured in days, a draft tool has a real job. If nobody can recall one, the problem is too infrequent to build a product around, however annoying it feels in the moment.

What makes a communication idea good?

• A delay you can time. The idea removes a wait you can measure in hours or days, such as an unanswered email or a booking waiting for confirmation.
• A person stays in the send step. Tools that send on their own risk spam complaints and blocked accounts, and the user loses the chance to catch a bad draft.
• Consent from everyone in the conversation. If the tool joins, records or transcribes a call, every party has to know, and the rules differ by country.
• Output shaped for its channel. A two-line chat reply, a formal email and a short text message are different products, not one template in three costumes.
• A reason the sender cannot do it alone. A polite email is easy to write. Keeping twenty threads current with their history is the part people want to hand off.

The cold-call idea on the board passes the first and second points easily. Its difficulty is the third: a live prompt tool needs a clear answer to who hears the prompts and who has agreed to be recorded, which the pitfalls section below takes up.

What is the smallest version worth sending?

Hypothetical example: a reply drafter for one inbox. The user connects nothing. They paste an email thread and pick the outcome they want, and the tool returns two short replies, one friendly and one firm. They copy the text into their own mail program.

Input: a pasted thread of up to 2,000 words, and one outcome chosen from confirm, decline, ask for a date, or apologize.
Output: two drafts under 120 words each, and one line naming any fact a draft assumes.
Not in v1: mailbox access, sending, templates per client, team accounts.
Test: ten people use it for a week. Count the replies sent from a draft, and note how many were edited before sending.

Because the version never touches a mailbox, it needs no account permissions and no sending rights. That keeps the first test about the quality of the writing rather than the cost of an integration.

What are the pitfalls for communication apps?

• Recording without consent. Recording or transcribing a call is regulated, and the rules differ by country and, in the United States, by state. Some places require every party to agree. Put the consent step inside the product rather than in the terms page.
• Bulk sending and spam rules. Automated or bulk messages run into provider policies and anti-spam law. Keep a human approval step for anything sent on a user’s behalf, and an unsubscribe path for any marketing message.
• Impersonation. A draft that sounds like a named person, or a message that poses as a real company, is a trust problem before it is a legal one. Keep the user’s own name in the output and nobody else’s.
• Sensitive detail in messages. Emails hold health, money and legal details. Process only the text the feature needs, keep it briefly, and say so on the first screen.
• Disputes over slots. A tool that allocates limited ad or booking slots decides who gets seen. Publish the rule, and apply it the same way to every buyer.

Treat this list as questions to bring to a lawyer in your market, not as a compliance checklist. Consent and marketing rules change, so read the current text before you open the product to users in another country.

Which delay to attack first?

Pick a delay you can see in your own inbox or calendar. Two ideas on the board already aim at delays of this kind: Draft replies for the emails you keep avoiding and Live prompts during a cold call.

To add a communication idea of your own, write it up with a submission for this category: the delay, the person who waits, and the step that stays human. Then how to validate an app idea describes a five-user test, and how to write an app build prompt shows how to hand a first version to a coding agent without the consent step getting lost.