What Should a Client Ask Me Before Hiring Me?

What should a client ask me before hiring me?

Ask me who does the work, what happens when the estimate is wrong, and what I would consider a failure on this project. Those three answers tell you more than any portfolio. Most buyers ask about timelines and price instead, which are the two things every specialist has learned to answer smoothly.

I have worked on more than seventy projects for over twenty-five clients across more than six years, and the ones that went badly almost always had a version of the same root cause. Something important was assumed rather than asked, usually in the first conversation, usually by both of us.

So this is the article I would hand to somebody about to hire me, or anybody like me. It is not a trap. Good questions are easier to answer honestly than vague ones, and a specialist who resents being asked is telling you something useful for free.

Why am I telling you how to interrogate me?

Because a well-briefed client is cheaper to work with than a trusting one. When you know exactly what you are buying, you stop asking me for reassurance and start asking me for decisions. That is a better use of both our time and it produces better work.

There is a selfish version of this too, and I would rather say it than pretend otherwise. Questions like these filter out the engagements I am wrong for. If somebody asks what happens after launch and does not like my answer, I would much rather learn that in week zero than in week nine.

It also works in the other direction, and I have written up what I am trying to establish from my side of the same call in what a first sales call should actually establish. Reading both should make the conversation shorter.

The wider point is that hiring a specialist is not like buying software. There is no trial. You are buying judgement, and judgement can only be assessed by asking someone to exercise it in front of you. Every question below is really a request to do that.

What should you ask about pricing?

Ask what happens when the work turns out to be bigger than expected. Not what it costs, which anybody will tell you, but who absorbs the difference when the scope was misjudged. That single question separates people who price on confidence from people who price on optimism.

I price fixed fee, most of my projects land between one thousand and ten thousand dollars, and I publish that range rather than making you ask, for reasons I set out in the piece on publishing my pricing. That means when I have misjudged something, that is my problem, not a change order. I do it that way because I think the person with the most information about how long something takes should carry the risk of being wrong about it, and on a specialist project that person is me. I wrote out the reasoning in the piece on why I charge fixed fees.

The follow-up worth asking is what is explicitly not included. A good answer is specific and slightly awkward. A bad answer is that everything is included, which is never true and means the awkward conversation is simply being deferred to a worse moment.

What should you ask about who actually does the work?

Ask who will be in the file, by name, and who you will be talking to on a Tuesday afternoon when something is wrong. With me the answer is that it is me on both counts, which is either exactly what you want or exactly what you do not, and you should know which before you sign anything.

This question matters more than people realise because the gap between the person who sells and the person who delivers is where most disappointment lives. It is not dishonest for a larger team to hand work to someone else. It is only a problem when nobody told you, and the way to avoid that is to ask.

The honest trade-off with a solo specialist is capacity and coverage. You get the person you evaluated, working on your thing, with no translation loss. You also get one calendar, and if that calendar is full in March then March is not available. Anyone who tells you there is no trade-off here is selling.

What should you ask about what happens after launch?

Ask what you will be able to change yourself, and what will require coming back. Then ask what the handover actually consists of. A site or an automation you cannot maintain is not an asset, it is a dependency with a nice interface.

My answer is that the things you will want to change weekly should be yours, and I build with that in mind. Content, copy, the items in a collection, the rows in a table. The structural things are where you would come back, and I would rather tell you that plainly than imply you will never need me again.

Ask specifically about documentation, and ask to see an example from a previous project. Everybody says they document. The artefact tells you whether it is a real habit or a line in a proposal. If there is nothing to show you, assume there will be nothing to hand you.

How do you find out if someone has done your specific job before?

Describe the ugliest part of your situation and watch whether they recognise it. Not the project as described in your brief, but the part you are slightly embarrassed about. The legacy system nobody will replace, the stakeholder who changes their mind, the data that is not as clean as anyone admits.

Someone who has genuinely done the work will respond with a specific question rather than reassurance. When somebody tells me their CRM data is messy, I want to know which fields and who is allowed to edit them, because those two answers decide whether the job is a week or a month. If the response to your ugly detail is just that it will be fine, nobody has seen that problem before.

Use their background as a prompt rather than a credential. I came into this from aeronautical engineering, which turns out to matter less than people expect and more than nothing, because it left me suspicious of systems that work fine until they do not. Whatever background someone has, ask them what it makes them look for. The answer is more revealing than the qualification.

What should you ask about how they will measure success?

Ask what number they expect to move and when they expect to see it. Then ask what would make them tell you the project had not worked. A specialist who cannot describe their own failure condition has not thought about your outcome, only about your deliverable.

For the work I do, this is usually visibility, citations, conversions or hours saved, and the honest answer includes a timeline that is longer than either of us would like. Search and answer engines do not move in a fortnight. Automations show their value faster but only after they have survived a few weeks of real use.

Be suspicious of guaranteed numbers, particularly in anything touching search. I can tell you the work I will do and why I believe it moves the thing you care about. Anyone promising you a specific position or a specific percentage is either lucky, vague enough to escape later, or counting on you not checking.

What is the question that makes most people uncomfortable?

Ask who they turned down recently and why. It is uncomfortable because the answer reveals whether somebody has a practice or a pipeline. A specialist who takes everything is telling you that your project will be competing for attention with work they did not want.

I turn down work fairly regularly, usually because the problem is not one I am the right person for, occasionally because the way a project starts tells me how it will end. That is not a boast, it is just a description of how a small practice stays functional. I wrote about the reasoning in the piece on saying no to bad-fit clients.

The version of this for you is to ask directly whether your project is a good fit, and to make it genuinely easy to say no. Say it out loud: tell me if this is not for you. Most people will take that invitation if you offer it, and the ones who cannot take it under any circumstances are the ones to worry about.

What should you not bother asking?

How many years of experience someone has, and how many clients they have worked with. I have the numbers and I will give them to you, but they predict very little. Six years of the same year is not six years, and twenty-five clients means nothing if none of them looked like you.

I would also drop the question about which tools they use, at least as an opening. The tool matters far less than the judgement about when to use it. Somebody who will happily build your thing in a spreadsheet when a spreadsheet is correct is usually more valuable than somebody committed to a platform.

Portfolio browsing is worth less than people think as well. A portfolio shows you what got finished and approved, which is a filtered view of both the work and the client. One honest conversation about a project that went wrong tells you more than ten case studies that went right.

What should you do next?

Pick the three of these that matter most for your situation and put them in your first email rather than saving them for a call. Written answers are more considered, easier to compare across people, and much harder to charm your way through.

Then notice how the answers are given rather than only what they contain. Specific, slightly uncomfortable, willing to say what is excluded. That combination is what competence sounds like, and it is remarkably consistent across trades.

If you are weighing up whether to bring someone in for search visibility, automation or a Webflow build and you want a straight answer about whether it should be me, reach out and ask me these questions directly. I will tell you if it is not a fit, and that costs you one email.