
The things we got wrong
This page is a log of mistakes—not a list of achievements. Every site makes errors, but most hide them. Here, we name the ones that mattered, and how we fixed them. It’s the only way to prove we’ll keep fixing them.
The reader gets a direct way to judge this site: if we admit what went wrong, we’ll admit what still does. No transparency is worthless if it’s not tied to consequences. And if a mistake isn’t here, it means we’re still making it.
Three we had to fix
These are the failures that changed how we work. The first was a guide that sent readers to a broken download link for a month.
The second was a review that misquoted a product’s specs, and the third was a troubleshooting tip that didn’t work on half the machines it claimed to. None were intentional. But they all got worse before they got fixed.
How we correct our mistakes
- 1The broken download link
A tutorial on fixing a corrupted Windows update file linked to a direct download that stopped working after the source server was taken offline. It stayed live for 28 days before a reader flagged it. We pulled the article, rewrote the download section with a manual verification step, and added a ‘last tested’ timestamp to every guide. Estelle Kessler caught it after a reader emailed the contact page.
- 2The misquoted hardware specs
A review of a mid-range SSD claimed it had 560MB/s read speeds, but the actual benchmark was 530MB/s. The error came from copying the manufacturer’s marketing sheet instead of the real-world test. We corrected the review, added a ‘verified by’ note for all benchmarks, and banned marketing materials as sources. Estelle Kessler spotted it when comparing notes with a reader who’d emailed the discrepancy.
- 3The failing troubleshooting tip
A guide to resetting a frozen Linux system suggested running `sudo systemctl reboot` from a TTY, but it failed on systems with Secure Boot enabled. We rewrote the step to include Secure Boot checks, added a ‘tested on’ list for every OS version, and made comments visible only after submission review. Estelle Kessler fixed it after seeing the same question asked five times in a row.
What those three changed

These mistakes forced rules we now follow: no live content without verification, no specs without direct testing, and no ‘one-size-fits-all’ fixes. The log exists because the alternatives—silence or excuses—are worse.
Rules that came from mistakes
- Every download link must be manually verified within 48 hours of publication. *(From the broken download link)*
- Hardware specs must come from benchmarks, not manufacturer claims. *(From the misquoted specs)*
- Troubleshooting steps must include edge-case notes (Secure Boot, third-party kernels, etc.). *(From the failing tip)*
The people behind this

Estelle Kessler is the founder and editor of *File Fix*. She’s the one who signed off on every correction here—because the only way to trust a log of mistakes is to know the person who keeps it.
And the only way to trust that person is to see them admit when they were wrong.
Keeping this list isn’t comfortable. It means writing down failures in public, where they can be judged. But the alternative—pretending we never make them—is a lie. The best tech guides aren’t the ones that never crash; they’re the ones that explain what happens when they do.
The smallest mistake I made here wasn’t public: I once spent two hours trying to fix a misbehaving USB port by unplugging every other device in the house, only to realise the port was loose. The real fix was a screwdriver.
I still think about that every time I write a troubleshooting guide.
If you find something wrong on this site, don’t just tell us—tell us *how* it’s wrong. The contact page is where to do it. And if you’re reading this and thinking *‘I’ve done that before’*, you already know how it feels. That’s the point.
There will be a next one
This list isn’t finished. The next mistake might be a typo in a code snippet, a missed compatibility note, or a guide that works for 90% of readers but not the 10% who need it most.
When it happens, it’ll be here—because the only way to prove we’re serious about fixing things is to show the ones we haven’t fixed yet.
If you spot something, the contact page is where to report it. No need to guess if it’s important; we’ll decide that. But if it’s a mistake, we’ll fix it—and add it to the log.
The guides are grouped by category: App, Coding, Hardware, Operating System, Outlook and PowerPoint.
