What 'project done' means for a senior engineer (not a PM)

A project is done when the last commit hits prod. That's how juniors think about it.

For me, a project is closed when I can walk the next person through three things in 20 minutes and stop receiving calls. I didn't figure this out early. I figured it out after one project came back 8 months later with a question that wasn't in any ticket, any doc, or any commit message.

"Done" vs "closed": the difference that costs you sleep

"Done" means production. It works. Tasks are resolved. Contract fulfilled.

"Closed" means the project lives without you. Whoever takes over next month or next year can understand how the critical pieces fit together without calling you.

That sounds like a small distinction. In practice, it's the difference between a clean exit and 40 hours of unplanned consultations spread across the next year.

A PM measures closure differently. Delivered on time, invoice accepted, paid. For them, project closure is an administrative event. For me, it's technical and communicative. The client got the product. The question is: who now owns the understanding of how it works?

Project handoff is about transferring understanding. The code is already there.

What you carry out of a project

When you leave a project, you take three things with you. The client doesn't think about this because they don't know these things exist.

First — the context behind architectural decisions. Why it's built the way it is. What alternatives were considered. Why headless and not a monolith. Why Elasticsearch and not a SQL LIKE query. This context isn't in the code. It's not in git history. It's in your head.

Second — the map of danger zones. Every production project has three to five spots where a change will break something in a non-obvious way. Hidden dependencies. A cache that needs warming after each deploy. A Bitrix component that only works with a specific OPcache configuration. The next developer doesn't know about these spots. They'll find them at 3am.

Third — the list of unresolved decisions. Deliberate compromises made because there wasn't time to do it right. Technical debt both parties know about but nobody wrote down. It doesn't disappear after handoff.

All three need to be transferred explicitly. Otherwise they stay with you, and you pay for it in time.

The technical passport: three pages that save a night years later

I call it the technical passport. Three pages maximum. More than that and nobody reads it.

Page one: the architecture map. Services, what talks to what, where the data lives. Not a conference slide — a map for the person who'll be debugging an incident tomorrow morning. Plus: non-standard decisions with their reasons. "We're using Redis not for sessions but as a notify queue — because RabbitMQ would have been overkill for this RPS."

Page two: the danger zone map. Specific files, tables, components. With a note on what breaks if you touch them without understanding. This isn't code documentation — it's warnings for the person who'll work with the code after you're gone.

Page three: open decisions. Compromises still sitting in the code. What was planned for refactor but didn't happen. Short explanation of why. This is honesty toward everyone who'll touch the project after you.

Three pages. I write them in two to three hours at the end of a project. Once, this saved me roughly 40 hours of consultations over the following year.

The closure conversation with the client

Most project handoffs go like this: "Everything working? Great. Payment confirmed? Good. Good luck."

I run a separate meeting — the closure. An hour, sometimes less. Topics: what's being transferred and to whom. Who's responsible for what now. Where the technical passport lives. What to do if something breaks in the first 30 days.

The client rarely asks for this themselves. But when you offer it, the reaction is always positive. Because it's about their peace of mind, not your reputation.

I document everything in writing. Not to cover myself — but so a year from now we're not arguing about who said what.

What we left after the 28k SKU headless migration

The last major project: headless architecture for a catalog with 28,000 SKUs on Bitrix + Next.js. When we closed the project, the technical passport included the following.

Architecture map: where the catalog lives (Bitrix iblock 40), how Next.js pulls data through the REST proxy, why not GraphQL. Where Elasticsearch sits and what it indexes. The cache invalidation schema — a non-obvious point: invalidation fires on a webhook from Bitrix. If the webhook doesn't arrive, data goes stale silently.

Danger zones: three items. OPcache on the Bitrix server resets on deploy. That's normal. But if the OPcache configuration changes, Bitrix starts reloading components on every request — TTFB jumps from 0.4s to 2.1s. Second: Next.js ISR cache invalidation only works when the REVALIDATE_SECRET environment variable is present. If it disappears, pages stop updating without throwing an error. Third: Elasticsearch doesn't sync with Bitrix products automatically on batch import. You need an explicit trigger via cron or webhook.

Open decisions: inventory sync between Bitrix and the external WMS is written as polling — it should have been event-driven, but we didn't have time. That's the next step when the volume scales.

The whole passport: two and a half pages. The client handed it to the next team four months later. I didn't get a call.

My personal definition of "closed"

The last commit in prod is the beginning of closure. Not the end.

For me, a project is closed when:

• the technical passport is written and handed over
• the closure meeting happened and the outcomes are in writing
• the client has answers to three questions: who maintains it, where are the danger zones, what was planned but not done

This takes one to three days. Depends on project size.

I've written before about closing risks instead of tickets in day-to-day work. That's about the ongoing mindset. This is about the final transfer.

Most incidents that come back to me six months later are information I didn't hand over at the end. Not because I hid it. Because I assumed it was obvious.

It wasn't obvious. One call at 8 months was enough to change that.