Summary — the conclusion first
Publishing one blog post took too many manual steps. Title, summary, category, translation, cache — eleven of them.
So I built a tool to do it in one shot. The point wasn’t “automation.” It was making the writing actually get read.
And building it taught me one thing. Building is easy; shipping is hard. This post is my first act of shipping.
Why I built it — the same eleven chores
Every time I published, I repeated the same manual steps. I counted eleven.
- Write the title
- Write the summary
- Add a category
- Add tags
- Post the Korean version
- Translate to English
- Link the two as a translation pair
- Convert to web format
- Publish
- Purge the cache
- Check the URL is alive
Once is fun. By the tenth time it’s a chore. I’d forget to link the English version, or skip the cache purge and see the old post.
It’s chopping the same vegetables in the same order every time. You don’t memorize the recipe — you build a meal kit.
The real problem wasn’t automation — it was “does anyone read it?”
Automation was half of it. The bigger half was whether the published post actually gets read.
People don’t read. They scan. Nielsen Norman Group found people read only 20–28% of the words on a page.
“Made to Stick” has a scarier experiment. People tapping out a song’s rhythm guessed listeners would name it half the time. The real rate was 1 in 40.
The writer hears the melody; the reader hears only taps. That gap is the “curse of knowledge” — assuming others know what you know.
So I made readability a “security gate”
I decided to force readable writing: a checker that blocks publishing if the post fails.
Think of a password check. Too short, you can’t sign up. Same here — miss the bar, the post doesn’t go up.
The checks came straight from the research.
- Is the conclusion at the top — the first sentence of each section is the answer
- Is any paragraph too long — long ones get skipped
- Are there enough subheads — signposts for scanners
- Is any sentence too long — out of breath, can’t read
- Are there analogies and examples — abstract doesn’t stick
This post got caught too. My draft ended with a clever little flourish I thought was modest. The checker called it a common cliché. I cut it.
To me it was style; to the reader, filler. A small case of the curse of knowledge — the checker caught the gap for me.
An unexpected win — write it well once, gain in three places
Tidying for readability paid off in more than one place. Three, actually.
A post that’s easy for humans to scan is easy for search-and-summarize AI to quote. Search now shows AI-assembled answers, and it cites posts with the conclusion up top and short paragraphs first.
A well-organized post is also easy to share — you can lift the three key lines as they are.
One lever, three doors: humans, AI, and sharing all point the same way.
Failure log — raw
Nothing went smoothly. Here are the snags, as they were.
The tool rejected my text. One way of moving the text tripped a security filter, so I routed around it.
It didn’t show in the menu. I built the skill but it wasn’t listed. A single config line at the top of the file was missing. I only found it by comparing with a tool that worked.
The English URL collided. Using the same address as the Korean version made the system append a number. I gave the English version its own address.
Behind every clean result there’s this kind of small breakage.
The stack — infrastructure included
I won’t hide what runs it.
The blog runs on one small PC at home. On it, WordPress in Docker, with a multilingual plugin pairing Korean and English.
External access goes through a Cloudflare tunnel. Drafts are handled by free gpt-4o, and I wrote the readability checker in Python myself.
What I actually learned — building is easy, shipping is hard
This is the one thing that stuck. Building a tool is comfortable; shipping is not.
| Building | Shipping | |
|---|---|---|
| Control | in my hands | others’ reaction |
| If you slip | just fix it | people see it |
| Feeling | comfortable | uncomfortable |
| Growth | small | large |
So I keep wanting to build more tools. It’s the comfortable side. But growth is on the uncomfortable side.
So I write this. Not leaving the made thing as-made, but putting it out. This post itself is that practice.
One line
I built the tool to force readable writing, but the real lesson was elsewhere: building is easy, shipping is hard — so ship.
Sources
- Nielsen Norman Group, “How Users Read on the Web” — only 20–28% of words read
- Chip & Dan Heath, “Made to Stick” — the curse of knowledge, the tappers experiment
- Diátaxis — four documentation types (tutorial, how-to, reference, explanation)