Ask Who Reviews Your Work Before You Take the Job

People usually say "bad client" when they mean a cheap one. Low budget. Haggles. Wants it yesterday.

That isn't the client who hurts you. You can see cheap in the job post, before you even bid. You can price for it or walk away.

The client who hurts you is the one with no definition of done. Nobody on their side reads your code, runs your tests, or fills in a security questionnaire about it. Then one day somebody does. A buyer, an investor, an enterprise customer's security team. Your work fails a review you never knew was coming. Your name is on every commit.

So the discovery-call question worth asking has nothing to do with budget. It's this:

"After I ship, who reviews this work, and what do they need to sign off?"

That one question tells you three things. Whether a done line exists. Who draws it. Whether you'll be paid to reach it.

The call notes

Here's the artifact. A plain notes file from a discovery call, with the four answers you'll hear most often.

# discovery-call.md
Q:  After I ship, who reviews this work,
    and what do they need to sign off?

A1: "Our CTO reviews PRs. We have a security audit coming."
A2: "An investor will do tech due diligence next round."
A3: "Nobody. Just make it work."
A4: "We'll know it when we see it."

Now line by line.

1. The question itself. "After I ship" makes them picture the handover, not the kickoff. "Who" assumes someone exists. That's deliberate. Asking "will anyone review this?" gets you a lazy "no." Asking "who" makes them think about it. Ask it early in the call, before you discuss price. If you ask after the number is on the table, the answer bends toward whatever keeps the number low.

2. A1: named reviewer, named standard. This is the best answer you'll get. There's a real person and a real bar. You can scope against it: tests on the risky paths, a README, a dependency check, sensible logging. Ask for the audit checklist or PR template on the call. Then price it in. A client who already has a reviewer is also the one most likely to keep you on afterwards. That's the path in From One-Off Gig to Retainer: The State Change.

3. A2: real reviewer, vague timing. Due diligence means a stranger reads the repo cold. They'll have no context and no patience. What they need to see: setup that works from the README, no secrets committed, clear module boundaries. Follow up with one question: "Has a review like this happened before, and what came back?" A past report is the best spec you'll ever get.

4. A3: "Nobody." This is the filter. "Nobody" today means a stranger later, and you're the only name to blame. It isn't an automatic no. Ask a second question: "Who owns this code a year from now?" If the answer is still nobody, you have two options. Write the handover material yourself and charge for it, or walk.

5. A4: "We'll know it when we see it." Red. No reviewer, no criteria, and a target that moves. Every revision is unpaid and every argument is unwinnable. This sits in the same family as the warning signs in Red Flags in a Job Post: Before You Bid, Read This. The only difference is you caught it on a call, not in the post.

Answer	What it really means	What you do	Cost if you ignore it
A1: named reviewer + standard	Done is defined	Get the checklist, scope to it	Low
A2: future due diligence	Done is defined later, by a stranger	Scope for a cold read: docs, setup, no secrets	Failed DD lands on your code
A3: nobody	Done is undefined until a crisis	Ask about ownership, charge for handover, or walk	You're blamed for gaps nobody asked you to fill
A4: we'll know it	Done never arrives	Decline, or fixed scope with written acceptance	Endless unpaid revisions

If you're the founder on the other side of this call, take the question as a favor. An engineer who asks it is building for the next person who opens the repo. That person might be your auditor.

The scope change

But the question only matters if the answer changes your proposal. If you write down "CTO reviews PRs" and then send the same quote you'd send anyone else, you wasted the question.

Turn the answer into acceptance criteria. Put them in the statement of work, in plain words a non-technical founder can approve:

Acceptance criteria (from discovery call)
- Reviewer:   [name / role from the call]
- Must pass:  CI green, tests on payment and auth paths
- Ships with: README, .env.example, deploy runbook
- Excluded:   compliance controls outside the app code

That block does four jobs. It names who says "done." It defines done in checkable terms. It lists the handover material as deliverables, not favors. And it fences off what you aren't responsible for. That last line is what protects you when an audit flags something in their infrastructure, not your code.

The follow-up checklist, in order:

1. Ask for the actual document. Security questionnaire, PR template, DD checklist, last audit report. Whatever exists. A reviewer you can't read is a guess.
2. Name the reviewer in the SOW. A role is fine if they won't give a name. "Whoever" isn't fine.
3. Line-item the handover. README, environment example, setup steps, runbook. Each one with hours against it. If it isn't priced, it gets cut when the deadline slips.
4. Write the exclusions down. Infrastructure, third-party vendors, policies, anything outside the code you touch. Reviewers don't care whose fault a finding is. Your SOW does.
5. Re-ask at kickoff. Reviewers change between the call and the contract. One sentence in the kickoff message confirms it.

Expect pushback on step 3. Handover line items are the first thing a client tries to trim. Treat it the same way as any price objection. The "Can You Do It Cheaper" Message: A Receipt for Handling It Without Losing the Job or Your Rate covers the response. The short version: cut scope, not the rate, and don't cut the parts a reviewer will check first.

The clients worth keeping answer the question easily, because they've already thought about it. The ones who can't answer are telling you who will define done: someone you'll never meet, at a time you don't choose, holding your code up against a standard nobody showed you.