8 questions before a contract
I started using this list after a 2024 contract that went sideways for reasons I'd technically been told about during the intake conversation. The owner had mentioned, casually, that the last freelancer disappeared mid-project. I heard the words and didn't process them. Three months later I understood what they'd been telling me.
The script exists because intake conversations are full of information that only registers as warnings after you've experienced the equivalent failure mode. The eight questions force the warnings out before signing.
Order matters. Skipping the early questions makes the later ones impossible to interpret correctly.
01 — who has the final yes
The single most important question. Not "who's the point of contact." Who has the final yes.
The answer pattern that's a green flag: a single person, named, with explicit authority over the budget and the scope. Sometimes that's the founder. Sometimes it's a department head. The point is that one person can say yes and the work proceeds.
The answer pattern that's a red flag: vague references to "the team" deciding, multiple stakeholders mentioned but no decision hierarchy, or worst — the point of contact admitting they need to "check with leadership" for any non-trivial decision. The contract will become a committee. The committee will not deliver consensus on time. You will be the one absorbing the delay.
The Hino Motors contract worked partly because this was clean from day one. The contract that went sideways in 2024 had the warning here and I missed it.
02 — what does done look like
The question forces a concrete definition of shipped. Not in vague terms. In specific, observable terms.
Bad answers: "users can log in and do the main thing"; "the platform works"; "the migration is complete."
Good answers: "the SOC 2 auditor signs off on this list of 14 controls"; "1,500 employees can log in via Active Directory and submit a workflow form successfully"; "the Stripe integration handles the payment edge cases enumerated in this PDF."
The good answers have observable acceptance criteria — something specific that, when true, the contract ends. The bad answers leave the goal posts where they can be moved.
03 — what's the timeline they actually have
Not what they say the timeline is. What it actually is.
This is harder than it sounds. Clients overstate timelines for two reasons: they want the work to feel less urgent (so you'll accept a lower rate), or they want it to feel more urgent (so you'll prioritize them). Both happen. Both produce different mistakes.
The diagnostic question I add: what happens if this slips by 30%? The honest answer to that tells you whether the timeline is fixed or negotiable. If the answer is nothing breaks; we accommodate, the timeline is soft. If the answer is we miss the launch event, the parent company pulls funding, we lose the partner deal — the timeline is hard. The contract terms should reflect which.
04 — what's the budget shape (not number)
I almost never ask for the number first. The number is performative. The shape is informative.
The shape questions:
- Is this a fixed-price project, an hourly engagement, or a milestone-based delivery?
- Are payments triggered by calendar (monthly invoicing) or by deliverable (milestone acceptance)?
- Is there a budget review at any point, or is the budget locked at signing?
- What happens if the scope expands during the contract? (The answer tells you whether change orders are a process they know how to handle.)
A client who can answer all four questions clearly has done this before. A client who can answer none of them is going to be a process you're partly running for them. Either is fine — but you need to know which.
05 — who's already worked on this
The question that uncovers the project's graveyard.
Most non-trivial contracts have at least one previous attempt — a previous freelancer, an internal team, a stalled agency engagement. The previous attempt's outcome predicts the new one more reliably than the client's optimism does.
If the answer is we've tried twice and it didn't ship — the third attempt is unlikely to be different unless something structural has changed. Different freelancer with the same brief and the same stakeholders and the same scope is the same setup. The successful third attempt usually involves a narrower scope or a different decision-maker.
The contract that went sideways in 2024 had three previous freelancers. I was the fourth. I should have asked the question the way the answer to it could land.
06 — what's the rollout plan
After it's built, who lands it into production. Who teaches the team. What happens 30 days after launch when bugs surface.
If the answer is we'll figure that out closer to launch, the answer is I will be doing it. Build that into the contract from the start. The mid-project surprise of oh, also you'll be running the deployment / training / on-call is the most predictable scope creep in freelance work.
The Hino contract handled this well — there was a clean handoff plan from day one. Other contracts I've taken treated post-launch support as an unsolved problem the freelancer would solve at launch time. They were always wrong about that.
07 — what's a no for you
The question that names my constraints out loud.
I have specific lines I won't cross: I don't do crypto-casino frontends, I don't take projects where I can't credit the work publicly in some form, I don't do exclusivity clauses on the entire freelance practice. Naming the no-list during intake prevents misalignment later.
It also signals seriousness. Clients who appreciate a clear no-list are usually the clients who have their own clear lists. Clients who push back on any no-list are usually the clients who want the contract to expand without resistance.
Tactical version: have the no-list written down somewhere before the call. Reading from a list is calmer than improvising one.
08 — when do we sign
The closing question. The one that converts the conversation into a commitment.
Deferring this question is the most expensive mistake in freelance pipeline management. A client who is enthusiastic in the call but doesn't have a date to sign is a client who is still shopping. Defer for two weeks and they often go cold — not because they didn't like you, but because the energy of the call dissipated and a competing priority overtook the decision.
The question to ask: if we close today's call agreeing on shape and budget, when would you want the contract signed and the start date locked? The answer either is a specific date — which means the deal is real — or is hand-waving — which means it isn't yet.
the one i never skip
Question 01 — who has the final yes.
The 2024 contract that taught me this list failed because the answer to question 01 was a committee. I knew there was a committee. I thought the lead would manage them. He couldn't. Three months in, the scope was being relitigated weekly by three different stakeholders with three different opinions about what the project actually was.
The single signal that predicts whether a freelance contract will end well: one person, named, with explicit authority over budget and scope. If that doesn't exist, you're the person who's going to absorb the cost of the missing decision-maker.
I'd take a less interesting project with a clear decision-maker over a more interesting project with a committee, every time, now. The decision quality of the people you work with predicts the project quality more reliably than the brief itself does.
That's the question I never skip. The other seven are negotiable depending on context. The first one is non-negotiable.