← Back to blog

Why I Keep a 'Never Again' List Between Projects

After every project I open the same note and add one line. Not "what went well" — that goes in the team retro. Just one thing: what I won't do on the next project.

Two years in, there are 23 entries. Some of them cost clients money. Some cost me.

This isn't a lessons-learned document for the team. It's a personal file, and it changes how I talk to a new client before the project even starts.

Why project lessons disappear

Retrospectives solve a team problem: how did we work together? Personal decisions don't survive there.

After one project I realized I'd taken an integration without API documentation. Standard risk, standard mistake. I wrote it in the retro. Six months later I took another project. Same situation, no docs. Same problems.

Knowledge in your head doesn't count. Only what's written down.

Best practices age fast. Frameworks get replaced, contracts change, the market moves. A list of your own mistakes doesn't age. The pain was real — you remember it more accurately than any methodology.

What my list actually looks like

Simple structure. No special tool — mine is plain text in Obsidian:

Date: 2023-04-10
Project: Bitrix e-com, catalog ~8k SKU
Category: estimation
Entry: don't estimate a catalog migration without profiling first
Consequence: underestimated by 2x, lost three weeks

Three categories: technical decisions (architecture, tools, integrations), client work (contract, scope, expectations), and estimation. The last one is where I'm wrong most often.

Specific mistakes. Specific consequences.

Five entries from the last two years

Real entries. Names and some numbers changed to protect clients, but the shape of each mistake is intact.

  1. Don't start a project without an architecture audit.

A client wanted to do a full Bitrix rewrite for a store with 28,000 SKUs, budget around $40K, timeline three months. They were sure Bitrix was "slow." I asked for two days. Turned out it was custom queries without indexes and a misconfigured OPcache. A rewrite would've been three months of unnecessary work. I turned the contract down. Since then: diagnosis first, estimate after.

  1. Don't agree to an integration without API documentation.

"The docs exist, we just need to clarify a few things with their dev" is a red flag. I heard that twice. Both times "clarify" stretched to three weeks and changed the scope. Now it's in the contract explicitly: documentation before kickoff, or the integration phase is scoped separately with a variable budget.

  1. Don't estimate performance issues without profiling.

When a client says "the page is slow," the first instinct is to look at the code. That's a trap. LCP 3.8s could be the server, the CDN, a third-party analytics script. No estimate before profiling. After one project where I spent a week optimizing queries and moved LCP by 0.1s, I wrote this entry and haven't broken it since.

  1. Don't close a ticket — close a risk.

If the task is "add a button" and you add a button, fine. But if that button touches cart logic, auth, and the 1C sync, it's not a ticket. It's a risk. I stopped measuring my usefulness through velocity. Now I ask: what risk does this task actually close? More on that in this piece on risk thinking.

  1. Don't take a project from a client who can't name a success metric.

"I want it to be better" isn't a metric. "Cart conversion should go from 2% to 3%" is a metric. If by the third call the client still can't give me a number, there are two options: help them define one, or don't take the project. Without a metric there's no delivery criterion, and without a delivery criterion the project doesn't end.

How it differs from a retrospective

Retros are team exercises. They focus on process: standups, blockers, sprint velocity. That's useful.

But retros are public. In a public document you don't write "I underestimated by 2x because I was overconfident." You write "planning needs improvement." Politically neutral. Personally useless.

The personal list is about decisions. What specifically I decided, what broke, what I won't repeat. It stays with me on the next project. The retro document doesn't.

How the list changes client conversations

In pre-sales I open the list and scan quickly: does this client show patterns from any of my entries? No API docs — check entry two. Talking about a "slow site" without numbers — entry three. It's a filter.

When I'm hiring, I ask: "Do you have a list of things you'd never do on your next project?" If they do, I'm immediately more interested. Means they're thinking past the current task.

The minimal template to start

Three columns:

| What I did | What happened | What I won't repeat | |---|---|---| | Took integration without docs | 3 extra weeks | Docs required before contract |

Tool doesn't matter: Obsidian, Notion, a Google Doc, a text file. One rule: write the entry right after deploy or right after something breaks — while the pain is fresh.

Six months from now you'll read it and remember details you'd have otherwise forgotten completely.

Best-practice guides age. Frameworks change, markets shift. A list of your own mistakes doesn't. The hurt was real — which means it stuck.

If you already have a list like this, I'd be curious to compare notes — DM me. If you don't, the deploy after your next project is a good place to start.