When to kill a blog post you’ve already spent hours on

If you are using AI to write blog posts for your personal brand, the pull will be to publish whatever you spent hours on. The draft feels expensive. You ran it through three rewrites. You ran the prompts. You sat with it. The math in your head says “I spent the time, the post should go live.”

That math is a trap. The time you spent does not change whether the post is worth your reader’s time. It only changes how attached you feel to the version sitting in front of you. That bias has a name: the IKEA effect. The more you build something yourself, the more you overvalue it. The longer you draft, the harder you fall for it.

The cost of publishing a weak post is bigger than the cost of killing it. Weak posts sit next to your strongest writing, and the reader who finds you through one and bounces is the reader who never came back to read the strong ones.

This post is the story of a draft I rewrote around five or six times before scrapping it, the reader test that should have killed it sooner, and the upstream question I now ask before I write a single sentence. If you ever sit on a draft past the point where it stopped getting better, the test below saves you the next weekend.

The post I rewrote five or six times before killing it

The post slot was supposed to be a how-to. The topic was a narrow setup task tied to my own publishing system. It worked for my setup, my stack, and my archive structure, but it would not translate cleanly to most of the readers I actually write for. I had done the work. I had the order of operations. I had a working version of the thing the post was teaching.

I started drafting, and the first version felt off. I asked the AI to rewrite. The second version was still off. I asked again, and again, and again. Five or six versions in, I sat with the latest draft and read it from the top.

Not as the writer this time. As the reader. Someone around my age, building his own personal brand on the side, who comes to my work because he wants help with what he is trying to build. Would he finish this post? Would he get to the end and feel like he got something out of it?

The honest answer was no. He would close the tab. He might think “WTF did I just read” and never come back. The post was technically correct. The steps were right. But there was no reason for him to care, because the setup task was specific to a setup he probably did not use.

I sat with that answer for a minute. Around five hours in. Five or six rewrites deep. A draft that was almost good enough by the writer’s eye. A draft that would have failed the reader’s eye every time.

I scrapped it. Not “shelved for later.” Not “rework next week.” Killed it. The slot in the publishing sequence went empty. I moved on to the next post on the list and let the gap stand on the blog where anyone walking through the archive could see the number was missing.

How do you know when to kill a blog post?

The test I should have run at hour two instead of hour five is simple. Read the draft from the top, in one pass, without editing. Read as the reader who follows your work, not as the writer who knows what you meant. Would they finish this? Would they walk away with something they can use?

If the honest answer is no, you have your kill signal. It does not matter how many times you have rewritten. Almost there at hour five is still not there. Another rewrite will not change the underlying problem.

By rewrite four, I was reading the draft hoping it was working. Hope is not a test. Hope is a sign you have already lost objectivity. Run the test as the reader, and run it earlier. Their answer is the only one that counts.

The earlier question that would have ended it at hour one

Here is the question I now ask before I open a draft.

What does this post teach my reader about building their personal brand specifically?

Not “is this interesting to me.” Not “did I do something cool.” Not “would I want to read this.” The reader is not me. The reader is someone with a different setup, a different week, a different problem. The post earns its slot only if the lesson lands for them, in their setup, with their constraints.

The killed post failed that question and I did not ask it before I started writing. The setup task was specific to my own situation. Most personal brand builders are running different setups. The lesson the post was reaching for was real but applied to a small slice of readers. To make it useful for everyone else, I would have had to stretch the story beyond what was actually true.

If I had asked the question at hour zero, I would have either reframed the post around a lesson that fits more readers, or I would have moved on to a different topic. Either way, no five hours lost. No five or six rewrites. No killed draft.

The hours I spent fighting the draft were the cost of skipping a one-minute gate.

Why I left the gap on the blog instead of forcing a fix

After I killed the post, I had a choice. I could write a different post for the same slot. I could renumber the rest of the sequence to close the gap. I could quietly slide everything up so the archive looked clean.

I left the gap. The slot is empty. Anyone walking through my blog archive will see the number is missing.

The reason is simple. The catch-up arc is a chronicle of how I built this personal brand, mistakes and all. Hiding the kill would have made the archive look smoother than the real build was. The empty slot tells the truth. I tried, I failed, I called it, I moved on. That is the discipline I want the reader to see. Not a varnished version where every post lands.

If the gap is part of the story your archive is telling, let it stand. For me, the catch-up arc is proof that I am building this in real time, so a missing post is part of the story. Your archive might be a different shape. The principle that travels: do not clean up the proof when the proof teaches the point.

Put This Into Practice

If you have a draft you have been fighting with for more than two rewrites, here is the prompt I would paste into Claude or ChatGPT today. Do not ask the AI to rescue the draft. Ask it to judge whether the draft deserves to be rescued.

I have a blog post draft I have rewritten more than twice and it is still not landing. Help me run the kill-or-keep test on it. Walk me through these questions one at a time and wait for my answer before moving to the next.

  1. Read the draft I am about to paste in. Tell me the one thing the reader walks away with. If you cannot name it cleanly, that is a flag.
  2. Would a real reader who follows my work finish this draft? If not, where would they quit, and why?
  3. What does this post teach my reader about building their personal brand specifically? If my answer is “this is interesting because I did the work,” tell me that is not the same as serving the reader.
  4. Am I improving the draft, or protecting the time I already spent? Push back if I sound attached.
  5. Based on those answers, tell me honestly whether to keep editing this draft or kill it and move to a new topic. The wrong answer is the one that protects the time I have already spent.

Run the prompt. If the answer is kill, kill the draft and move to the next topic. The hours you save are the hours you put into the post that actually serves the reader.

The empty slot is the lesson

The post I killed was supposed to be a setup how-to. It would have been a competent post for a small audience. It would have been a weak post for everyone else.

If you walk back through this archive, you will see the jump. Where post number 47 should be, the sequence goes from 46 straight to 48. The lesson the killed post could not teach is the one you are reading right now.

Six rewrites told me the draft was not getting better. Five hours told me I was attached. The reader test told me to scrap it. That order should have been reversed.

For the related discipline of cutting the phrases you got attached to before they earn their spot, the tagline post covers the same move applied to language. For the bigger architecture decision behind the publishing system this gap sits inside, the one source three channels post covers why I write one post per topic instead of three.

The reader is the test. The clock is not.

~ Anthony

◆ Come build with me

The build log.

New post drops, tool tests, and the occasional honest look at what isn't working. One email at a time. Unsubscribe in one click.

Anthony Tran

Anthony Tran

Marketer. Air Force veteran. One person building a personal brand with AI, in public. Writing and recording from Chandler, Arizona.

Frequently asked.

When should you kill a blog post draft?

Run the reader test. Read the latest draft from the top, in one pass, without editing. Read as a reader who follows your work, not as the writer who knows what you meant. If the honest answer to 'would they finish this' is no, kill the draft. The number of rewrites does not change that answer.

How do you avoid wasting hours on a blog post draft that should be killed?

Ask one question before you start writing. What does this post teach my reader about building their personal brand specifically? Not 'is this interesting to me.' Not 'did I do something cool.' If the answer is anything other than a clean yes, reframe the topic or skip it. The hours you save are the hours you put into a post that actually serves the reader.

Is it OK to leave a gap in your blog if you scrap a post?

Yes. If you scrap a draft, do not paper over the gap. Let the missing number stand on the archive. The honesty is part of the personal brand. Hiding the kill makes the archive look smoother than the real build was. Build-in-public means the whole build, including the parts you chose to leave on the floor.