Three Conversations Before the Project Starts That Saved Me Six Months of Pain

My most expensive project didn't cost me money.

It cost me five months of rework. Because the client and I had different definitions of "done." I thought done meant deployed and working. He thought done meant matching a mental model of the product he'd never said out loud.

The code was correct. The architecture held. We were just building different things.

I now run three conversations before I open an editor on any new project. Each one takes 30 to 40 minutes. Together they've saved me far more than those five months.

"We discussed everything" is an illusion

Every new project has an early moment of mutual enthusiasm. The brief is agreed, the budget is signed, the launch date is in someone's calendar. Everyone nods. Everyone says yes — but each person is saying yes to a different thing.

The client says "yes, let's do it" meaning "plus those extra things I didn't write into the brief — those are included, right?" The developer says "yes, we'll build it" meaning "exactly what's in the spec, and nothing else."

Those two yeses aren't the same word.

Scope creep isn't usually malice. It's almost always mismatched assumptions. The client wasn't hiding anything. They just didn't know their expectations needed to be said out loud. And the developer wasn't missing requirements — they simply treated the spec as the complete picture, because it was the only picture they had.

Three conversations don't eliminate ambiguity. They make it visible before someone's already paid for it.

Conversation one: what "done" means — out loud

This is the strangest of the three, because the reaction is almost always the same: "Well, done means it works."

Works is not a definition.

I ask a specific question: "What has to happen for you to tell me the project is closed?" Not "what features should be in it" — "what will have happened." That's a different question.

Because "works" can mean:

• features are live in production with no critical bugs
• features are live and have passed client acceptance testing
• features are live, staff have been trained, documentation is written
• features are live and the project has shown 30 days of metrics

All of these are "works." They're also very different amounts of work, at different timelines, for different prices.

After the conversation I write the Definition of Done directly into my follow-up email: "Based on our discussion, the project is considered complete when: [three specific points, no 'and so on']." I ask the client to add what's missing.

They often add things. Not because they were trying to hide requirements — but because seeing the list made them realize it didn't include something they'd assumed was obvious.

On one project, the client added a note after seeing my DoD email: "We also need the ability to add promo banners ourselves, without coming back to the developer." That was a week of work we'd have discovered after delivery. Finding it before was better.

Conversation two: what we're NOT building — in writing

My rule: every spec gets a list of three to five items labeled "what's not in this project." Not to shrink the scope — but because without an explicit "no," every "no" sounds like a refusal.

Typical items on the list:

• loyalty system integration — that's a separate project
• mobile app — not in this phase
• content SEO optimization — outside the development scope

Clients read the spec and see what's written. They don't see what isn't written. Two months later, someone asks: "Why isn't there automated email follow-up?" — and it's a completely reasonable question from their perspective. It was always in the picture in their head.

An explicit out-of-scope list turns that conversation from a conflict into a calm "right, we agreed without that — let's estimate it separately."

I learned this the hard way. On one project I spent six weeks on a feature the client considered "obviously included" and I considered clearly outside the contract. Neither of us was wrong. We just both assumed the other understood the boundaries the same way we did.

After I started writing the out-of-scope list, that kind of conflict stopped. Not because clients got easier. Because we had a shared document to refer to.

When something new comes up mid-project — and it always does — we add it to a change list with a separate estimate. Not "we won't do that," but "that's outside the current scope; here's what it would take."

Conversation three: who decides when we disagree

Most projects have multiple people with opinions. The executive who approved the budget. The marketer who'll use the system. The IT person who'll maintain it. Sometimes all three want different things.

I don't need to know who's right. I need to know whose "yes" closes a question.

I ask this directly: "If we disagree on a technical decision during the project — who makes the final call?" It's an uncomfortable question. It's also necessary.

Without an answer, I can agree on something with one person, spend two weeks building it, then hear from someone else that it needs to be redone because "he doesn't make decisions, I do."

Everyone's technically correct. The project just has no single decision point. I've lost two weeks that way.

Now, at the start of every project, I ask explicitly: "Who is the principal? Who gives final sign-off on technical decisions?" If there are two people in that role, I need to understand how they resolve disagreements between themselves — because that process will eventually involve me.

This isn't about hierarchy. It's about the fact that a developer shouldn't be the mediator between two equally-ranked stakeholders.

Why this benefits the client, not just me

I know how this sounds: the developer invented three ways to protect himself from the client. But the numbers don't work that way.

Scope creep costs both sides. The client pays for rework they didn't expect, ends up with a trimmed product when the budget runs out, or misses their launch window when the project runs long. Pick one — they've all happened on projects I've seen.

Those five months I spent on that expensive project were five months the client didn't have a working product. That wasn't only my loss.

A Definition of Done, an out-of-scope list, and a named decision-maker are tools for transparency, not self-protection. The client knows what they're buying. I know what I'm delivering. That's just a clear deal.

I hear this from clients fairly often after a first project together: "I'm glad you discussed this upfront. We used to find out about these things mid-project." That's not a compliment to my negotiation skills. It's confirmation that most developers don't do this.

How these conversations evolved

The early versions were worse.

At first I just asked "do you agree with the spec?" and thought that was enough. Then I added the explicit out-of-scope list and immediately felt the difference. Then the decision-maker question — that solved a whole class of problems I hadn't had a name for.

The Definition of Done came last, and turned out to be the most valuable. Because the question "what has to happen for you to tell me it's done" isn't really about technical acceptance criteria. It's about how the client thinks about outcomes at all.

Two hours before the project starts. That's the real investment. I haven't worked on a single project where it didn't pay back.

If you want the step before this one — figuring out which clients to work with before you sign anything — that's in How I spot a difficult client before the project starts. And if you want the mindset underneath all of this, the shift from closing tasks to closing risks, that's in I stopped closing tickets. I started closing risks.