❯ From Support Answer to Article: Recycle Your Expertise

2026-09-24 ·5 min read

by Jonas Reyes — the builder's desk, Side Quest Studios September 25, 2026

You already wrote the article. It's buried in your ticket queue.

I was on a call last week with an ops lead who'd spent four hours debugging a systemd unit that kept restarting under load. By the end he knew exactly why — RestartSec too aggressive, StartLimitBurst tripping, the whole thing thrashing. He explained it to me in three minutes flat. Then he said, "I should write this down somewhere." Somewhere. That somewhere is the article. That ticket is the draft. You just haven't published it yet.

Here's the thing about the current moment: everyone's writing think-pieces about AI agents and risk management and the future of work, and almost nobody is writing down what actually broke and how they fixed it. The Fast Company piece on companies deploying agents with "no idea how to manage risk" is real — but the fix isn't a white paper. It's the runbook you wrote at 2am. That runbook is content. That support thread is content. That postmortem doc nobody reads is content.

Your support queue is a content goldmine

Pull your last 90 days of tickets. Filter for the ones where you spent more than 30 minutes. You'll find maybe 15-20 that are genuinely interesting — the kind of problem that has a non-obvious answer. Those are your articles.

Here's the actual command I use to pull this out of Zendesk's API:

import requests
from datetime import datetime, timedelta

after = (datetime.now() - timedelta(days=90)).isoformat()
url = f"https://yourdomain.zendesk.com/api/v2/search.json?query=type:ticket created>{after} status:solved"
r = requests.get(url, auth=("user", "token"), headers={"Authorization": "Bearer YOUR_TOKEN"})
tickets = [t for t in r.json()["results"] if t.get("resolution_time_in_minutes", 0) > 30]

Swap the auth for whatever you actually use. The point is: you're not brainstorming topics. You're querying your own history. The topics already exist. They're just sitting in a database.

I've been doing this for years. The pattern is always the same. You solve something hard, you explain it in a comment or a Slack thread or a support reply, and then you think "that was good, I should turn it into a post." Then you don't. Six months later you hit the same problem and have to re-derive the answer from scratch because you never wrote it down properly.

Write it down. Publish it. The version you write for yourself is 80% of the version you'd write for an audience.

The three-pass edit that turns a ticket into a post

Don't try to write an article from scratch. That's how you end up with a draft folder full of half-finished 400-word stubs. Instead, take the support answer you already wrote and run it through three passes.

Pass one: strip the specifics that don't matter. The customer's hostname, their specific version of Postgres, the exact error message that's only relevant to their setup. Keep the shape of the problem.

Pass two: add the part you left out. When you answer a support ticket, you skip the "why" because you're trying to unblock someone fast. In the article, you explain the "why." Why does RestartSec=5 cause a thundering herd? Why does the default StartLimitIntervalSec bite you under load? That's the value. The fix is the hook. The mechanism is the article.

Pass three: add the failure mode. What happens if you don't fix it? What does it look like when it goes wrong at 3am? This is the part that makes people bookmark the page. Not "here's the fix" but "here's the four-hour outage you avoid by knowing this."

I ran this process on a piece about journalctl log rotation last year. The original ticket was 200 words. The article was 1,400. The only thing I added was the mechanism and the failure mode. It's still one of the top three pages on the site.

You don't need a content calendar. You need a `git log`.

The content strategy people will tell you to build a calendar, batch your writing, pick three pillars, blah blah blah. Ignore them. You already have a calendar. It's your git log.

bash bash (80x24)

git log --since="3 months ago" --pretty=format:"%s" --no-merges | sort | uniq -c | sort -rn | head -20

That's your editorial calendar. The commits you made that took more than a day to figure out are the articles. The ones with "fix" in the message and no explanation are the ones you should write about because you didn't explain them.

Same for your shell history:

bash bash (80x24)

history | awk '{$1=""; print}' | sort | uniq -c | sort -rn | head -30

If you ran a command 40 times in the last quarter, that's a topic. If you ran it 40 times and it's non-obvious, that's a good topic. The fact that you had to run it 40 times means you kept forgetting the syntax — which means your reader will too.

The best piece I ever wrote came from noticing I'd typed systemctl daemon-reload about 60 times in one month. That's not a command you should need to run 60 times. The article explained why systemd doesn't pick up unit file changes without it, and what to do instead. That's it. Nine hundred words. It still gets traffic.

Stop waiting for the perfect angle

The reason most engineers never publish is they think they need a novel insight. They don't. They need a clear explanation of a thing that already exists and that people already struggle with.

Look at the current news cycle. Everyone's writing about AI agents and CAPTCHAs and risk management. The takes are all the same — either "this is fine" or "this is terrifying." Nobody's writing the operational piece: how do you actually sandbox an agent so it can't exfiltrate data? How do you log its actions so you can audit them later? What does a cgroup look like for an agent process that's allowed to make outbound HTTP calls but not write to disk?

That's the article. Not "AI agents are coming." The piece nobody's written is "here's the iptables rule I use to keep my agent from phoning home."

You have that knowledge. You've already solved that problem. You just haven't written it down.

The publishing part is the easy part

Static site generator. Markdown files. git push. If you're using anything more complicated than that, you're overthinking it. I run my whole site on a $5 VPS with nginx and a Makefile that runs pandoc and rsyncs the output. Total build time: four seconds. Total cost: less than a coffee per month.

build:
    pandoc -s --template=templates/post.html -o public/$(SLUG).html posts/$(SLUG).md
    rsync -avz public/ user@vps:/var/www/html/

That's it. That's the whole pipeline. You don't need a CMS. You don't need a headless anything. You need pandoc and rsync and the willingness to hit enter.

The hard part isn't the tooling. The hard part is deciding that the thing you already explained once is worth explaining again, in public, where someone else can find it.

The compounding effect nobody talks about

Here's what happens after you publish 20 of these. You stop getting the same support tickets. Not because the product got better — because the answer is now the first result when someone searches for the error message. You've turned your support burden into documentation. You've turned your scar tissue into a knowledge base.

I've watched this happen three times now. The first ten articles feel like shouting into the void. Articles 11 through 20 are where it starts to click. By article 30, you've got inbound leads from people who found the answer to their problem on your site, read three more posts, and decided you clearly know what you're talking about.

That's the whole game. You're not writing content. You're writing the documentation you wish existed when you hit the problem the first time. The audience is just everyone who hits it after you.

Go pull your last 90 days of tickets. Pick one. Write the mechanism. Publish it before Friday. The draft is already in your queue.

References

AI-assisted, curated for Side Quest Studios.