For founders and indie builders posting on X

X posts and replies that don’t all sound the same

You are building in public and posting on X every day. Ask an AI X post generator for a week of posts and they converge: one hook style, one length, one closing line. Replies to other builders start with the same move, so your account starts to read like a template.

Unsame changes the approach and form (such as the opening or length) your AI uses each time you write the same kind of thing. Your AI writes the words; Unsame writes nothing.

Start free See a real example

A real example

One input, three takes.

A take is one version of the text. Below, a real input runs through the starter template three times, and a real model writes each take from the protocol (the short instruction Unsame returns). Voice and rules stay the same; the approach and form change. Beside each take is what the same model wrote from the same input with no protocol.

Written by

X posts

Daily posts for a builder or small company account.

Input

why we stopped writing a changelog entry for every small fix

= Same every run

Situation
planned post
Engage with
why we stopped writing a changelog entry for every small fix
Always
use one concrete detail: a number, a name, a date or a before state, taken from the input or from work we can point to
Voice
plain, first person, specific, no emojis, no hashtags
Never
claim a number we cannot show, name a competitor, end with a generic call to follow or retweet, use em dashes (—) or stock phrases like "here's the thing", "let's dive in" or "game-changer"

Plain prompt · Claude, no protocol

With Unsame · a varied play each run

  1. Run 1
    Plain prompt

    We used to write a changelog entry for every small fix. A typo in an error message sat right next to a breaking change, and readers had to dig for the line that mattered. Now small fixes get grouped, and each entry answers one question: what changed for you?

    With Unsame

    contrarian_take

    • closer none
    • length long_post_up_to_1000_chars
    • opener statement

    A longer changelog looks like more transparency. For us it worked the other way. We used to write an entry for every small fix. A typo in a label, a spacing tweak, a one-line bug: each got its own line, with the same weight as a change that altered how people actually used the…

    How this play was written

    state the common belief, flip it, then give one fact from our own work that supports the flip

    Situation: planned postEngage with: why we stopped writing a changelog entry for every small fixApproach: state the common belief, flip it, then give one fact from our own work that supports the flipForm: length: long_post_up_to_1000_chars; opener: statement; closer: noneWrite: skip the first wording that comes to mind; Form sets the length, opening and ending.Always: use one concrete detail: a number, a name, a date or a before state, taken from the input or from work we can point toVoice: plain, first person, specific, no emojis, no hashtagsNever: claim a number we cannot show, name a competitor, end with a generic call to follow or retweet, use em dashes (—) or stock phrases like "here's the thing", "let's dive in" or "game-changer"
  2. Run 2
    Plain prompt

    We used to write a changelog entry for every small fix. Typo in a tooltip, a padding tweak, a log line reworded, all of it got its own line. The result was a changelog nobody read, because the changes that actually affected people were buried under the ones that didn't. Now…

    With Unsame

    story_with_turn

    • closer question
    • length under_280_chars
    • opener number

    1 entry per fix, however small. That was our changelog rule. But the changes that mattered got buried under typo fixes. Now small fixes share one line per release and real changes get the space. Shorter, easier to scan. What do you read a changelog for?

    How this play was written
    1. and: what we were doing
    2. but: the thing that went wrong or surprised us
    3. therefore: what we did, with the result
    Situation: planned postEngage with: why we stopped writing a changelog entry for every small fixApproach:1. and: what we were doing2. but: the thing that went wrong or surprised us3. therefore: what we did, with the resultForm: length: under_280_chars; opener: number; closer: questionWrite: skip the first wording that comes to mind; Form sets the length, opening and ending.Always: use one concrete detail: a number, a name, a date or a before state, taken from the input or from work we can point toVoice: plain, first person, specific, no emojis, no hashtagsNever: claim a number we cannot show, name a competitor, end with a generic call to follow or retweet, use em dashes (—) or stock phrases like "here's the thing", "let's dive in" or "game-changer"
  3. Run 3
    Plain prompt

    We used to write a changelog entry for every small fix. A typo in an error message got the same line as a new feature, and the changes people actually needed to know about got buried. Now small fixes get grouped into one line per release, and the changelog is back to being…

    With Unsame

    mistake_log

    • closer takeaway
    • length up_to_600_chars
    • opener question

    Who reads a changelog line that says "fixed typo in settings tooltip"? We kept asking that while writing one for every small fix. The log grew long, the changes people cared about got buried, and every merge carried a writing chore nobody valued. Now an entry has to pass one…

    How this play was written

    name one mistake we made or one habit we stopped, what it cost in time or money, and the rule we follow now

    Situation: planned postEngage with: why we stopped writing a changelog entry for every small fixApproach: name one mistake we made or one habit we stopped, what it cost in time or money, and the rule we follow nowForm: length: up_to_600_chars; opener: question; closer: takeawayWrite: skip the first wording that comes to mind; Form sets the length, opening and ending.Always: use one concrete detail: a number, a name, a date or a before state, taken from the input or from work we can point toVoice: plain, first person, specific, no emojis, no hashtagsNever: claim a number we cannot show, name a competitor, end with a generic call to follow or retweet, use em dashes (—) or stock phrases like "here's the thing", "let's dive in" or "game-changer"

X replies

Replies to posts and mentions that add something real.

Input

Hot take: you don't need a vector database for your side project. Postgres with a text index handled 200k docs fine for us.

Facts given to both

  • our search benchmark: Postgres full-text search with a GIN index answers 95% of queries in 40 ms on 200k docs
  • the whole index is 1.1 GB and runs on a 4 GB instance
  • we added a vector store later, only at about 2M docs, when we needed semantic ranking

= Same every run

Situation
a claim we agree with
Engage with
Hot take: you don't need a vector database for your side project.Postgres with a text index handled 200k docs fine for us.
Always
reference one exact detail from their post, so the reply could not be pasted under another post
Voice
plain, warm, specific, no emojis
Never
open with 'great point', 'this' or 'thoughts?', pitch our product unless they asked for a tool, argue about the person instead of the claim, use em dashes (—) or stock phrases like "here's the thing", "let's dive in" or "game-changer"

Plain prompt · Claude, no protocol

With Unsame · a varied play each run

  1. Run 1
    Plain prompt

    Matches what we saw at the same 200k docs mark. Postgres full-text search with a GIN index answered 95% of our queries in 40 ms, and the whole index was 1.1 GB on a 4 GB instance. We only added a vector store around 2M docs, when we actually needed semantic ranking. Keyword…

    With Unsame

    add_missing_angle

    • length short_paragraph
    • opener statement

    Our numbers at 200k docs match yours: Postgres full-text with a GIN index answered 95% of queries in 40 ms, and the whole 1.1 GB index ran on a 4 GB instance. The angle I'd add is what eventually pushed us to a vector store. It wasn't doc count. It was needing semantic ranking,…

    How this play was written

    name one angle their post leaves out and say how it changes their point

    Situation: a claim we agree withEngage with:- Hot take: you don't need a vector database for your side project.- Postgres with a text index handled 200k docs fine for us.Use:- our search benchmark: Postgres full-text search with a GIN index answers 95% of queries in 40 ms on 200k docs- we added a vector store later, only at about 2M docs, when we needed semantic ranking- the whole index is 1.1 GB and runs on a 4 GB instanceApproach: name one angle their post leaves out and say how it changes their pointForm: length: short_paragraph; opener: statementWrite: skip the first wording that comes to mind; Form sets the length, opening and ending.Always: reference one exact detail from their post, so the reply could not be pasted under another postVoice: plain, warm, specific, no emojisNever: open with 'great point', 'this' or 'thoughts?', pitch our product unless they asked for a tool, argue about the person instead of the claim, use em dashes (—) or stock phrases like "here's the thing", "let's dive in" or "game-changer"
  2. Run 2
    Plain prompt

    Matches what we saw at 200k docs too. Postgres full-text with a GIN index answered 95% of our queries in 40 ms, and the whole index was 1.1 GB on a 4 GB instance. We only added a vector store around 2M docs, when we actually needed semantic ranking. Keyword search gets you a…

    With Unsame

    concrete_case

    • length three_sentences
    • opener question

    Curious whether anything started to strain at 200k docs, or did it just keep humming? Our numbers line up with yours: Postgres full-text search with a GIN index answered 95% of queries in 40 ms on 200k docs, and the whole 1.1 GB index sat comfortably on a 4 GB instance. We…

    How this play was written

    describe one specific case from our own work, with the numbers, that backs or breaks their point

    Situation: a claim we agree withEngage with:- Hot take: you don't need a vector database for your side project.- Postgres with a text index handled 200k docs fine for us.Use:- our search benchmark: Postgres full-text search with a GIN index answers 95% of queries in 40 ms on 200k docs- we added a vector store later, only at about 2M docs, when we needed semantic ranking- the whole index is 1.1 GB and runs on a 4 GB instanceApproach: describe one specific case from our own work, with the numbers, that backs or breaks their pointForm: length: three_sentences; opener: questionWrite: skip the first wording that comes to mind; Form sets the length, opening and ending.Always: reference one exact detail from their post, so the reply could not be pasted under another postVoice: plain, warm, specific, no emojisNever: open with 'great point', 'this' or 'thoughts?', pitch our product unless they asked for a tool, argue about the person instead of the claim, use em dashes (—) or stock phrases like "here's the thing", "let's dive in" or "game-changer"
  3. Run 3
    Plain prompt

    Matches what we saw at 200k docs too. Postgres full-text search with a GIN index answered 95% of our queries in 40 ms, and the whole index was 1.1 GB on a 4 GB instance. We only added a vector store around 2M docs, and the reason was semantic ranking, not speed.

    With Unsame

    sharp_followup

    • length two_sentences
    • opener number

    200k docs lines up with what we saw: Postgres full-text with a GIN index answered 95% of our queries in 40 ms, and the whole 1.1 GB index lived happily on a 4 GB instance. At your size, did ts_rank ordering ever start to feel wrong to users, or did relevance only become the…

    How this play was written

    ask the follow-up that only someone who read the post closely would ask, about a mechanism or a trade-off

    Situation: a claim we agree withEngage with:- Hot take: you don't need a vector database for your side project.- Postgres with a text index handled 200k docs fine for us.Use:- our search benchmark: Postgres full-text search with a GIN index answers 95% of queries in 40 ms on 200k docs- we added a vector store later, only at about 2M docs, when we needed semantic ranking- the whole index is 1.1 GB and runs on a 4 GB instanceApproach: ask the follow-up that only someone who read the post closely would ask, about a mechanism or a trade-offForm: length: two_sentences; opener: numberWrite: skip the first wording that comes to mind; Form sets the length, opening and ending.Always: reference one exact detail from their post, so the reply could not be pasted under another postVoice: plain, warm, specific, no emojisNever: open with 'great point', 'this' or 'thoughts?', pitch our product unless they asked for a tool, argue about the person instead of the claim, use em dashes (—) or stock phrases like "here's the thing", "let's dive in" or "game-changer"

Setup

Set it up in 4 steps.

  1. 01

    Sign up free

    100 credits a month, no card.

  2. 02

    Pick the matching template

    Start from “X posts”, and from “X replies” if you answer other people’s posts. Each is a ready-made playbook: a list of approaches plus your voice and rules.

  3. 03

    Connect your AI

    Use Claude, Codex or another app that supports MCP (the standard way AI apps connect to outside tools).

    How to connect
  4. 04

    Paste the “Use this goal” prompt

    Open your goal, copy its “Use this goal” prompt into your connected AI chat, then give it your input. Your AI writes the text.

Questions

Fair questions.

Do posts and replies need separate setups?

Yes, they are two goals, each with its own playbook, because the moves differ: a post needs a hook, a reply needs to answer what the other person wrote. You can start both from the templates on the same account.

How does a reply know what to respond to?

Unsame reads the post you give it, works out which of your situations it is (for example a claim you agree with, or a question), and pulls out the points the reply must answer. Your AI receives those points together with the chosen approach.

Will this get me more engagement?

We do not promise that. What you can check is the result: a varied approach and form, grounded in the input, in a fixed voice. If you report which drafts you used, Unsame gives more weight to the approaches that worked for you.

Try it on your own input.

The free plan needs no card. Your model key stays with you.

Other use cases: Threads posts and repliesSupport repliesCold outreach

Start free How to connect