Stop looking for topics and look at work you have already done. One finished project contains an explanatory article, a tutorial, a case study, a reusable template and a list of future questions, and none of those require you to invent anything. The catch is that most of the material has to be collected while the work is happening, because the interesting part is the first thing your memory throws away.
What memory keeps is what you did. What it discards, quickly and completely, is what you nearly did instead. That is the part a reader actually wants.
- Having nothing to write about is nearly always a capture problem, not a topic problem.
- The option you rejected is what makes a case study readable, and it is unrecoverable afterwards.
- A broken state cannot be re-photographed once it is fixed. Capture at the moment.
- One project yields four to six honest assets, not fifty. Each must answer a different question.
- The questions you could not answer are your best article list, and they cost nothing.
Why you think you have nothing to write about
People who have done genuinely difficult work often believe they have nothing to say about it. The reason is not modesty. It is that finished work looks obvious in hindsight.
By the time a project is done, the solution feels inevitable to you. The dead ends have collapsed out of the story, the thing you were confused about in week two is now something you simply know, and the whole affair compresses into a sentence: we did this and it worked. That sentence is not an article, and correctly, you sense that nobody needs it.
The version of the project that is worth reading is the one that existed while you were still unsure. It is gone within weeks of finishing.
So the problem is not that the work lacked substance. It is that the substance was in the uncertainty, and the uncertainty is exactly what does not survive.
What memory deletes first
Three things go, in this order, and all three are the good bits.
The alternatives you rejected. You considered three approaches and picked one. Two months later you remember the one. The comparison, which is the single most useful thing you could tell somebody facing the same decision, is gone, along with your reasons.
The state of things when they were broken. You cannot photograph a bug after you have fixed it. You cannot reconstruct what the confusing interface looked like before you improved it. Before and after evidence requires the before to have been captured before it stopped existing, which sounds obvious and is almost never done.
The actual numbers. How long a step took, how many attempts it needed, how many items you processed. Reconstructed later, these become round approximations you are not really willing to stand behind, which means either publishing something soft or publishing nothing.
Five things to capture while building
All of these are cheap. Together they are perhaps ten minutes a week.
- A decision log. One line whenever you choose between real options: what you picked, what you rejected, and why. This is the highest value artefact on the list and the rarest.
- Screenshots of anything broken, confusing or ugly. Take them at the moment, not later. Storage is free and reconstruction is impossible.
- The failed attempts. A line each. What you tried, what happened, why you stopped. Readers trust an account with failures in it more than one without, and rightly.
- Questions people asked you. Every question from a colleague, client or tester is direct evidence of a gap in the explanation. It is also, verbatim, a heading for later.
- Rough measurements. Time per step, counts, sizes. Round numbers are fine as long as you noted them at the time and can say so.
Keep them in one file with the project. Not a system, not a tool with tags. A text file that you append to, because anything that requires maintenance will not survive a busy fortnight.
When you choose between two approaches, write the rejected one down along with the reason. "Chose B over A because A needed a database and this has to run offline." That single sentence is what turns a description of what you built into something a reader can use, because their constraints might differ and now they can tell.
The project to content map
Once the material exists, splitting it is mechanical.
| Part of the project | Becomes | Reader question it answers |
|---|---|---|
| The problem | An explanatory article | Why does this happen to me? |
| The process | A tutorial | How do I do it? |
| The decisions | A case study | How should I choose? |
| The repeated steps | A checklist or template | What must I not forget? |
| The reusable solution | Possibly a product | Can something do this for me? |
| The lessons | Short posts | What did you learn? |
| The results | Proof, used inside the others | Did it actually work? |
| The open questions | Future articles | What is still unsolved? |
The right hand column is the important one. If two assets answer the same reader question, you have not made two things, you have made one thing twice.
If the reusable solution row is looking promising, the question of whether it is actually a product is a separate one, and our guide on turning a work problem into a product covers how to tell.
Four to six assets, not fifty
There is a genre of advice that promises one piece of work can become dozens of posts. It can, in the sense that you can cut anything into small enough pieces. What you get is fragments that individually say nothing, which is why that approach produces feeds nobody reads.
The honest test is the one in the table: does this asset answer a question the others do not, for somebody who might not read the others? A checklist and a tutorial pass, because one is for a person doing it now and the other is for a person learning. A tutorial and a lightly reworded tutorial do not.
A substantial project honestly supports four to six pieces. A small one supports two. Publishing two good things is better for you than publishing twenty thin ones, and the search systems have been explicit that thin, duplicative content is not what they are trying to reward.
What you can and cannot publish
Most people doing client or employed work cannot simply write it up, and pretending otherwise would make this advice useless.
Three routes generally work.
Ask. More clients say yes than people expect, particularly if they get to review it and are named favourably. Ask when the work goes well, not months later.
Anonymise and keep the mechanism. Remove the client, the sector detail and anything identifying, and publish the method. "A marketing team producing a monthly competitor brief" carries the lesson without carrying the client. The mechanism is the valuable part and it is rarely confidential.
Rebuild it small. If the real project is unpublishable, reproduce the interesting part on something of your own. It also removes any question about ownership.
Check your employment agreement before publishing anything derived from work, and if the wording about confidentiality or intellectual property is ambiguous, get proper advice rather than guessing. Nothing here is legal advice.
A worked example from this site
This blog is mostly the by-product of building the tools, and the mapping is fairly literal.
The Premiere Pro Scroll Amplifier began with a specific irritation, a timeline that jumps to maximum zoom on one notch of the wheel. That produced an article about diagnosing and fixing the underlying cause, which is the problem row of the table, and a second article about navigating the timeline properly, which is the process row. Two different reader questions, one project.
Building TailWinks required working out why Tailwind v4 colours no longer paste cleanly into Figma, which turned out to be a change from hex to OKLCH. That investigation was the interesting part and it became its own article. The tool answers "can something do this for me", the article answers "why is this happening", and neither replaces the other.
The honest weakness in our own practice is the decision log. The rejected approaches on most of these builds were not written down at the time, which is why the articles explain what works rather than comparing it against what was tried and abandoned. That is a thinner article than it could have been, and it is the specific thing this piece is arguing you should do differently.
The tools these came from
Nine free browser tools, each one the reusable part of a problem we kept hitting. The articles are what was learned on the way to building them.
See the toolsWhere this does not apply
If the project genuinely went badly and you cannot say why, there may be nothing publishable yet. A failure written up without a diagnosis is not a lesson, it is a confession, and readers can tell the difference.
If your work is highly confidential and cannot be anonymised without removing the substance, the honest answer is that this project is not content and you should look for a different one.
And this is not a route to volume. It produces a small number of genuinely useful pieces from work you were doing anyway. If you need to publish several times a week, this will not fill the schedule, and the sensible response is to question the schedule rather than to thin the material.
Frequently asked questions
How do I create content from my work?
Start with a project you actually finished and split it by reader question: why this happens, how to do it, how to choose, what not to forget. Capture the decisions and the broken states while the work is live, because those are the parts you cannot reconstruct afterwards.
What if the project is confidential?
Anonymise the client and the identifying detail and keep the mechanism, which is usually the valuable part and rarely the confidential part. Otherwise ask permission, or rebuild the interesting piece on something of your own. Check your contract first.
How many pieces should one project produce?
Four to six for a substantial project, two for a small one. The test is whether each answers a question the others do not for a reader who might see only that one. Cutting a project into dozens of fragments produces posts that individually say nothing.
What if I did not capture anything and the project is finished?
Write what you can, which is usually the problem and the process, and accept that the case study is weaker without the decisions. Then start a decision log on the current project. The next write up will be much better and it costs almost nothing.
Is a decision log not just extra admin?
It is one line at the moment you were choosing anyway, so the marginal cost is close to zero. It also pays back inside the project itself, because six weeks later you will want to know why you ruled something out, and reconstructing that is far more expensive than noting it.
Should I write while the project is running or after?
Capture during, write after. Writing during tends to produce commentary on something unfinished, and you do not yet know which decisions mattered. The material has to be collected live, but the article is better with the ending known.
Where to start this week
Open a text file next to whatever you are currently working on and call it notes. For the next two weeks, add one line whenever you choose between options and one line whenever something breaks, and take a screenshot of anything that looks wrong.
At the end, read it back. The article you could not find before will be visible in that file, and it will be about the decisions rather than the outcome, which is the version worth reading.
How this was put together: this describes the practice behind the articles on this site, including where we have not followed it well, as noted above. It is not research and there is no data behind the claims about what memory retains, which are observations from doing this work rather than findings from any study. The four to six figure is a judgement about where useful stops and padding starts, not a rule. Anything touching confidentiality or contracts is general information rather than legal advice.