The worst project I worked on was not badly built. The code was clean, the deadline was met, the design matched the mockups. The client disputed the invoice anyway, the relationship ended badly, and I spent three weeks doing work I did not charge for.

The failure was not in the code. It was in the conversation that happened before the first commit.

The missing definition of done

"A landing page with a contact form" means a different thing to a developer and to a client who has been looking at Webflow templates for three weeks.

To the client, it includes: the animations they saw on a competitor's site, the mobile version matching their phone model specifically, a CMS so they can edit the copy themselves, and a response email sent automatically when the form submits. None of that was in scope. All of it was assumed.

A definition of done is not a feature list. It is a list of what the project explicitly does not include alongside what it does. The out-of-scope list is the one that protects both parties.

If a client resists defining what is out of scope, they are telling you something. It is worth hearing it before you start.

The budget that has not been decided yet

"We have budget, let's talk numbers later" is not a budget. It is a negotiation deferred to the moment when you have the most leverage and they have the least willingness to use it.

Rates discussed before the project starts are accepted or declined on their own terms. Rates discussed after two weeks of work and a Figma file the client likes are hostage negotiations in both directions.

Three things belong in the first conversation: what they need, when they need it, and what they are prepared to spend. Not a range. Not "it depends on what we land on." A number. If the number does not work, that is useful information. Finding it in week three is expensive information.

Feedback by committee

"I need to run it by my partner / co-founder / investor / cousin who works in tech" is a phrase that changes the project. Not because additional opinions are wrong, but because additional approvers who were not in the original conversation will have requirements that were not in the original brief.

The question is not "will other people be involved?" It is "who has final sign-off, and are they in this call?" If the person with approval authority is not in the discovery conversation, you are scoping for someone you have not met yet.

This adds a round to every feedback cycle. It adds ambiguity to every revision. And it creates situations where something approved in week one is reopened in week three because the approver was not in week one.

The red flags worth naming out loud

Three patterns that, in my experience, predict a difficult project:

— The brief changes between the first and second conversation without explanation. The client is still figuring out what they want. That is normal in month one of their planning, and early for month one of yours.

— The previous developer "just disappeared." Sometimes this is true. More often, the previous developer made a rational decision to stop working for reasons the client has not mentioned.

— They need it done by a date that was set before talking to you. External deadlines are real. Deadlines set before scope was defined are not project timelines — they are wishes. You will absorb the gap between the two.

What the alternative looks like

A discovery call that ends with a written summary of scope, exclusions, timeline, payment terms, and revision rounds. Sent by email. Replied to by the client. The project starts when that reply arrives.

This is not a contract substitution. It is a scope anchor. It takes twenty minutes to write and has saved me several times the cost of the hours I almost donated.

Conclusion

Most freelance project failures are baked in before the first commit. The code is usually not the problem. The conversation that defined the project — or failed to — is.

Summary

Scope failures start before the work does. A definition of done requires an explicit out-of-scope list, not just a feature list. Budget conversations deferred past the discovery phase become leverage conflicts. Committee approval restructures projects that were scoped for one decision-maker. Three reliable red flags: a shifting brief, an absent predecessor story, and a deadline that predates the scope. The fix is a written scope summary sent by email and acknowledged before any work begins.