A founder we work with wanted to write about a CTR collapse on his best-selling SKU. He had the number. He had the diagnosis. He wanted to show the search grid — the actual row of results where his product had gone from obvious to invisible against four competitors who had all redesigned inside the same quarter.
It didn't exist. Nobody had screenshotted it. You cannot re-pull a search results page from March.
The number survived because it lives in a report. The picture didn't, because it lived in a moment. He wrote the post anyway, and it was fine, and it was noticeably weaker than the one he was trying to write.
This is the gap the screenshot ledger closes. It's the capture bank for visual proof, and it is the only one in the series where the material is genuinely unrecoverable if you miss it.
Why This Isn't The Visual Asset Library
We've written before about building a visual asset library — 200 pre-built charts, frameworks and quote cards so a founder never delays a post waiting on a designer. That system solves a production bottleneck. You know what you want, you just can't get it made fast enough.
This solves an availability problem. You can't make it at all, because the thing you needed a picture of was a temporary state of somebody else's system and it has already been overwritten.
Different problem, different fix, and the second one has a deadline attached that nobody tells you about.
What Actually Expires
Founders assume proof is proof. It isn't. Proof splits cleanly into material you can reconstruct and material you can't, and almost nobody has sorted their own.
Reconstructable: unit economics, return rates, ACOS by campaign, revenue by SKU, review counts. All of it sits in a report you can pull again next year. Slower, annoying, still possible.
Not reconstructable, and specific to how ecommerce actually works:
- Search results grids. The single most valuable visual an ecom founder can publish, and it changes continuously. The competitive set you're describing in September does not exist in December.
- Your own listing before you fixed it. There is no public version history. The moment you upload the new hero, the old one is gone from every surface a reader could verify.
- A competitor's listing before they changed it. Same problem, except you also can't ask them for it.
- Report views with a rolling window. Several of the reports operators lean on hardest only look back so far. The window closes on its own schedule, not yours.
- Platform notifications and banners. The ones with a date and a deadline on them are the most quotable artefacts in the entire business, and they get dismissed by whoever opened the inbox first.
- A dashboard at the moment it moved. Not the number — the number persists. The shape: the drop, the spike, the two lines crossing.
- A supplier rate card, a fee page, a policy page before it was edited. Pages get updated in place, frequently without a changelog.
Every item on that second list is worth more in a post than anything on the first, because it shows a reader something rather than telling them. And every item on that second list has a shelf life measured in weeks.
The Rule: Capture At The Decision, Not At The Draft
The failure is always the same and it is never laziness.
The founder notices something on a Tuesday afternoon while doing their actual job. They think, correctly, that's interesting. They do not think that's a post, because at that moment they are not writing, they are working. Three weeks later they sit down to write and reach for the picture and it's gone.
So the rule is: you screenshot when you notice, not when you write. The trigger is the noticing, not the intention to publish.
That sounds obvious written down. It fails in practice because capturing feels like an interruption to the work, and the payoff arrives a month later to a version of you who has forgotten the interruption ever happened. It only becomes automatic once it takes under ten seconds, which is why the ledger has to be a single destination and not a filing decision.
The Six Fields
One row per capture. Keep it in whatever the rest of your banks live in.
- What it shows — one sentence, written as if to somebody who wasn't there. "Our SKU is fourth from left in row two and reads as the same product as the two either side of it."
- Date captured — automatic in most tools, worth having in the row anyway.
- Date of the data — different field, and the one people skip. A screenshot of a 90-day report taken in August describes May through July. Those are two different dates and only one of them is in the file name.
- Why you grabbed it — the thought you had in the moment. This is the field that saves the entry, because in six weeks the image alone will not remind you what was interesting about it.
- What claim it supports — links it to a proof bank or explanation bank entry. Screenshots almost never stand alone; they're evidence attached to an argument.
- Clearance status — publishable as-is, publishable after redaction, or internal only.
That last field is the one that turns this from a folder into a system.
Do The Redaction At Capture, Not At Publication
Ecommerce founders capture things that contain other people's information: supplier names on a quote, a client's brand on a dashboard, an ASIN sitting next to a revenue figure, a partner's logo in a portal.
The instinct is to grab it now and clean it later. Later is 11pm on a Sunday with a hook you already like, and at 11pm on a Sunday the two available options are "publish it and hope" or "don't publish." Both are bad, and the second one is why good material dies in a folder.
So the clearance decision moves to capture time, same as the rung decision in a disclosure ladder. Two minutes with a blur tool at the moment you grab it produces a pre-cleared version that sits next to the raw one. When you need it, there is nothing left to decide.
The general rule we hold to: publish the number or publish the identifier, never both in the same image. A revenue line with the ASIN cropped out is a data point. A revenue line next to a findable listing is competitive intelligence you're giving away for free.
Date It In Public, Or It Reads As Today
An undated screenshot reads present tense. That is not a small problem, it is the same failure as an undated receipt in a post: the founder is showing something they know is from March, and the reader is looking at something they assume is from this week.
Sometimes that gap flatters you. More often it quietly costs you the reader who checks, because a search grid from March describes a shelf that has since reorganised, and the operator who knows the category can tell.
One clause fixes it. "This is our category page as it looked in March." Nobody has ever been less impressed by a dated screenshot, and the founders who date them consistently end up reading as the person who keeps records, which is a positioning nobody can copy quickly.
The One Standing Capture Worth Building
Everything above is reactive. Here is the proactive version, and it's the highest-return thing in this post.
Once a week, screenshot the search grid for your main category term on your phone. Two rows. Ten seconds.
Do it for six months and you own something nobody in your category has: a time series of what the shelf actually looked like, week by week, as competitors entered, redesigned, ran out of stock, dropped price, and changed their creative. You will be able to show a reader the exact fortnight your category went from four distinguishable products to eleven near-identical ones.
That material cannot be counterfeited, cannot be bought, and cannot be produced retroactively by anyone — including you, if you start next quarter instead of this one. It is the closest thing to a proprietary dataset available to a founder for zero cost, and the only reason more people don't have it is that the value shows up two quarters after the effort does.
We've had clients start this and forget about it, and then produce a post eight months later that no competitor could write. That's the whole system working.
Frequently Asked Questions
Where should the files actually live? Wherever your other banks live, in one destination with no sorting decision at the point of capture. The failure mode is a founder with screenshots spread across a phone camera roll, a laptop desktop, two Slack channels and a DM to themselves. Sorting can happen weekly. Capturing cannot wait.
Doesn't this slow down the actual work? Ten seconds, and only on the days something is worth grabbing, which is not most days. The comparison isn't screenshot-versus-nothing, it's screenshot-versus-recreating-a-thing-that-can't-be-recreated. We've never seen a founder lose meaningful time to this. We've watched several lose their best post of the quarter to not doing it.
Can I publish a screenshot of a competitor's listing? Publicly visible pages, generally yes, and be deliberate about it. Our position is that you can show a mechanism without making it a message to a named company — the same logic we apply to score-settling posts. If the point survives with the brand cropped out, crop it out. If the whole point is which brand, you're not writing analysis, you're writing a subtweet with a business logo on it.
What about the captures I can never publish? Keep them. A screenshot you can't publish is still the thing that proves to you that a claim is safe to make, and the version you write from memory in eighteen months will be wrong in ways you won't catch. Internal-only is a legitimate clearance status, not a wasted entry.
How is this different from the proof bank? The proof bank holds numbers, which persist. This holds states, which don't. Most strong entries end up as a pair — a number in one bank, the picture that makes it land in the other — which is why field five exists.
If you're an ecommerce founder whose best proof keeps expiring before it becomes content, that's a systems problem, not a discipline one. We build the capture layer as part of every engagement, because the material is the constraint — not the writing. If you want that layer built rather than improvised, that's the part we do.