Seven signs a freelance engagement will go badly

You can see a bad engagement before it starts. One of these is a question. Two or three together is a reason to slow down.

Vague answers when you describe the work

If they cannot ask a follow-up or push back on your plan, they are not listening, or they have not done enough similar work to see the risk. Expertise shows up as a specific question, not instant agreement.

No checkpoints on anything larger than a small task

A developer who will only take full payment up front, and show you the result at the end, is asking you to carry all the risk. Small tasks can be prepaid. A product build should have something you can review.

They cannot explain a past decision

Portfolio links matter less than one story: a constraint, a choice, and what they would do differently. Generic answers usually mean they were adjacent to the work.

Code ownership is awkward

You should own the code, in writing, before work starts. Resistance to writing that down is the problem. Our pricing page states ownership on final payment because it should not be a negotiation each time.

The quote is far below every other quote for the same description

Sometimes they saw a smaller job than you described. Sometimes the corners show up in month three. Ask them to restate the scope in their own words before you celebrate the number.

Silence without a warning

Busy weeks happen. Repeated disappearance, with no message, is the flag. Ask how updates work before you start. “I’ll keep you posted” is not an answer. “A note when a milestone is ready” is.

No plan for when something is wrong

Bugs happen. A calm description of the support window is a good sign. Defensiveness is not. If they have never thought about a defect after launch, you will be the one who discovers the policy.

What to look for instead

Questions about scope. Milestones you can demo. Ownership in writing. A price in a range that matches the work they restated. An update cadence you could put on a calendar.

The technical interview is not the only variable. A strong developer who will not write things down can still sink the project. The next article, how to vet a developer, is the practical version of this list.