My Checklist Before Taking On a New Freelance Client
Every freelancer has at least one project they regret taking. Mine taught me that the technical scope was never the risky part — I can estimate code. What I couldn’t estimate early on was the client relationship itself, and by the time that became obvious, I was already three weeks in and financially committed. This checklist is what I actually run through now before I say yes to anything, built entirely out of contracts that went sideways.
Can they describe the problem, not just the solution? This is the first filter and it catches more than you’d think. A client who says “I need a React dashboard with these six features” has already decided the solution without necessarily understanding the problem it’s solving. A client who says “our support team spends two hours a day manually cross-referencing two spreadsheets” is describing a problem, and that’s someone I can actually help, because there’s room to push back if the six-feature dashboard turns out to be the wrong shape for the actual problem. If someone can only talk in solution-language and gets defensive when I ask “why this approach specifically,” that’s a signal the scope is going to shift constantly, because nobody’s actually agreed on what we’re solving.
Who signs off, and how many people is that really? I ask this directly now: “when this is done, who decides if it meets the bar?” If the answer is one person, great. If the answer is vague — “the team will review it” — that’s a red flag for a slow-motion scope creep where every stakeholder who never got asked upfront suddenly has opinions during final review. I had exactly this happen on a portfolio site project: the person who hired me loved it, then three other people in the company saw it for the first time at launch and each wanted different changes. None of that was in the original brief because none of those three people were ever part of defining it.
What’s the payment structure, and have they paid a freelancer before? Not a trick question — I ask it plainly. Clients who’ve worked with contractors before usually have a normal rhythm: deposit up front, milestone payments, a clear invoice cadence. First-time clients aren’t automatically bad, but I’ve learned to be more explicit with them about payment terms in writing, because “I’ll pay you when it’s done” from someone who’s never managed a freelancer isn’t malice, it’s just an assumption they don’t know is a problem yet. Getting a deposit before starting isn’t about distrust — it’s a small test of whether the payment process actually works before the stakes get higher.
Is the timeline theirs, or is it actually external? “We need this in three weeks” means very different things depending on whether that’s a preference or a hard external deadline — a fundraising deck, a conference launch, a contractual date with their own client. I ask directly now, because a soft preference has room to negotiate scope if something takes longer than expected, and a hard external deadline doesn’t. Knowing which one I’m dealing with changes how I plan the whole engagement, and it changes what I’m willing to promise in week one.
Do they already have infrastructure, or am I building the whole foundation? This affects both scope and my own workload more than clients usually expect. A client with an existing VPS, an existing CI pipeline, an existing design system is a fundamentally different project than one where I’m also standing up hosting, deciding the deploy process, and picking every dependency from scratch. Neither is wrong, but they’re not the same price or the same timeline, and I’ve underquoted more than once by not asking this early enough.
Can I actually picture a normal Tuesday working with this person? This is the least “professional” item on the list and the most useful one. Everything above can check out fine on paper and the relationship can still be exhausting day to day — constant Slack pings outside agreed hours, feedback that arrives as a rewrite of the brief instead of notes on the work, or a tone in early emails that already reads as impatient before any work has even started. I trust this instinct more than I used to. The contracts I regret weren’t the ones with hard technical problems. They were the ones where something about the early conversation felt slightly off, and I talked myself out of noticing it because the scope sounded interesting or the rate was good.
One more thing I added after a bad experience: I ask what happens if the project gets cancelled halfway. Not because I expect it, but because how someone answers tells me a lot. A client who’s thought about it says something like “you’d invoice for the milestone in progress and we’d part ways” — clear, fair, already considered. A client who gets uncomfortable or dismissive about the question (“that won’t happen, why are we even talking about this”) is someone who hasn’t actually thought through what a fair exit looks like, which matters a lot more the moment things actually go sideways. I added this one to the list after a project got cancelled by a client’s own internal reorg, with no plan in place for how to handle work already done. It got resolved, but it cost me a week of uncomfortable back-and-forth that a five-minute conversation up front would have avoided entirely.
None of this is about being paranoid toward new clients — most people I work with pass all of this without me even having to ask most of it directly, because it comes out naturally in a normal first conversation. The checklist isn’t a wall to keep people out. It’s just the list of questions I wish I’d asked out loud instead of assuming the answer, back when a good rate and an interesting stack were enough to make me skip past them.