How to Answer “What Are You Building?” on X

“What are you building?” looks like an easy question until you try to answer it. You know the roadmap, the architecture, and every problem the product could eventually solve. The person asking has none of that context.

A useful reply gives them a clear starting point: who the product is for, what someone does with it, and what exists today. You can then add the detail that fits this particular conversation. The aim is to make the project understandable enough for a real follow-up.

1Read the invitation before describing the product

The same question can mean different things. A general founder thread may invite a short introduction. A developer discussing local software may care about what runs on a device. A person reviewing onboarding tools may want to understand your specific use case.

Read the surrounding post and any constraints before replying. If the author asks for a screenshot, lead with something visible. If they ask what you shipped this week, describe that change rather than your entire company. If they explicitly invite links, a relevant link can belong in the answer.

Avoid treating every invitation as a request for the same pitch. Our guide to joining an ongoing conversation on X explains how to identify what the thread is actually discussing before adding your contribution.

2Start with a person and a task

A category alone leaves too much work for the reader. “An AI workspace for modern teams” names a broad space but does not explain what happens inside the product. Start with a person doing a recognizable task instead.

Consider a fictional product called Handoff. All product names, situations, and replies in this guide are illustrative, not customer stories or Replivio features. Handoff helps freelance designers collect client comments on a proposed design.

A useful first sentence might be:

I’m building Handoff for freelance designers to collect client feedback on a design in one shared review page.

The reader can picture a user, an object, and an action. They do not need to know the implementation to understand the basic idea. If you cannot write that sentence yet, describe the current problem you are investigating and say the product is still taking shape.

3Choose one concrete detail

Once the basic task is clear, add the detail that distinguishes the current experience. It could be a specific input, an output, or a step that works differently. Choose something observable rather than an adjective such as “seamless” or “powerful.”

For the fictional Handoff example, a concrete detail could be that comments attach to a marked area of the design. That is more informative than saying the tool makes collaboration effortless. It tells the reader how a particular action works without promising a result you have not established.

Do not turn the second sentence into an inventory. Version history, reminders, exports, and permissions may all matter later. In an introduction, they compete with the one detail you want the person to remember. Keep them available for a follow-up rather than squeezing them into the first reply.

4State the product’s actual stage

Distinguish what works now from what you intend to build. “Building a tool that sends review reminders” could describe a working feature or an idea on a roadmap. A short stage statement prevents the reader from assuming more than you mean.

You might say, “The review page is working; I’m testing the invitation flow next.” If only a prototype exists, say so. If you are researching the problem before writing code, explain what you are trying to learn. Each is a legitimate answer to the question.

For Handoff, a complete fictional introduction could be:

I’m building Handoff for freelance designers to collect client feedback in one shared review page. Clients can attach comments to a specific area of a design. The prototype works; I’m still testing how clients join a review.

This version does not need a traction claim. Add usage figures, outcomes, or customer names only when you have accurate information and permission to share it. An honest description of the current experience is enough to begin the conversation.

5Add a next step only when it fits

A reply can end after the introduction. You do not need to turn every exchange into a demo request, a signup link, or a discovery interview. Let the other person decide whether the project interests them.

When the thread asks for products to try, include the relevant destination and explain what someone can do there. If it asks for early work, a screenshot or prototype description may fit better. Check that the destination matches the stage you just described.

If you want feedback, choose one question the reader can answer from what you have shown. “Does this description make sense?” is broad. “Is it clear that the client leaves feedback without editing the design?” gives them a specific interpretation to check. For more examples, see asking for specific product feedback on X.

6Adapt the answer without changing the facts

Keep a short factual description you can reuse, but select details for the person in front of you. A designer may ask how comments are organized. A developer may ask about the implementation. A fellow founder may ask why you chose this problem.

The product should remain recognizably the same across those replies. Avoid describing it as a different solution just to match every thread. If their use case falls outside what you support, say where the fit ends instead of implying that a planned feature already exists.

You can use Replivio’s reply drafts to prepare wording, then edit the reply yourself. Verify the audience, current functionality, and stage before posting. In particular, remove any benefit or claim the draft adds that you cannot support.

7Read the reply as someone new

Before posting, read the introduction without mentally supplying the product knowledge you already have. Can a reader identify who uses it? Can they picture one action? Can they tell whether they could try it today?

If the answer depends on an unfamiliar acronym or an unexplained category, replace it with a concrete task. If several sentences repeat the same benefit, keep the clearest one. Your first reply only needs to establish shared understanding; the rest of the story can emerge when someone asks.

8Frequently asked questions