Client Communication Playbook: From First Response to Nurturing, Conversion, and Handover

1. The first response

"How much for an app like Uber?"

You'll get this one, or a version of it, every week. The tempting reply is a range: "somewhere between $30k and $80k." Don't. Any number you give now is either too high and scares them off, or too low and haunts you later.

The person asking usually doesn't want Uber. They want one piece of it: booking, live tracking, payments between two parties. Your job in the first reply is to find out which piece.

Happy to help with this. "Like Uber" can mean a lot of different things, so before I throw a number at you: who's booking, who's providing the service, and what's the one thing a user has to be able to do on day one? Is this a new product or are you rebuilding something that already exists?

Three questions, no pitch. The leads worth having will answer them. The ones who reply "just give me a ballpark" are telling you something too.

The two-line message at 11pm on a Friday

"Hi, need a developer for my project. Available?"

No context, no budget, no description. It's easy to ignore or to send a long template back. Both lose the lead.

Reply fast and short. Speed matters more than polish at this stage, because they've probably messaged four other people. A good reply asks for exactly one thing:

Yes, we are. What are you building? Even a rough description is fine and I'll come back with the right questions.

If you can't reply properly within a few hours, a one-line acknowledgement beats silence. "Got this, I'll reply properly first thing Monday" keeps you in the conversation.

What not to do

Don't open with your portfolio, your tech stack, or how many years you've been around. They haven't told you their problem yet, so none of it is relevant to them. Proof comes later, and it lands much harder when it's matched to what they actually need.

2. Discovery

"The other agencies are doing the estimate for free"

The client wants a full breakdown, a timeline and a fixed quote before paying anything. Two other agencies have offered exactly that.

We used to do this too. We'd spend days on calls, write up features, map out screens, and send a detailed estimate. Sometimes the client hired us. Sometimes they took our breakdown to a cheaper team.

Here's the thing: a free estimate is a guess dressed up as a plan. Nobody can price software properly without understanding the problem, and understanding the problem is real work. So we now offer a short, paid, fixed-price discovery phase. The client gets a written scope, a recommended approach and a real number. If they go ahead with us, the discovery fee comes off the build.

When a client pushes back, we don't argue about the fee. We explain what the free version leaves out:

We can give you a rough range today, but I'd be guessing, and so would anyone else who sends a fixed quote off one call. The paid discovery is how we get you a number we'll actually stand behind. You also walk away with a scope document you own, whether you build with us or not.

Some will still go for the free estimate. That's fine. The ones who see the value tend to be better clients.

The person you're talking to isn't the one who decides

Three calls in, everything's going well. Then: "Let me run it past my co-founder." The co-founder has never been on a call, has different priorities, and kills it.

Ask early, and ask plainly:

Who else will be involved in deciding on this? It'd be good to get them on the next call so we're not passing things back and forth.

If they can't or won't bring that person in, send a short written summary after each call that's easy to forward. You're writing for the person who isn't in the room.

When you have to say no

Sometimes the request is just not what you do. For us that's things like Java projects or training custom AI models from scratch. It's tempting to say yes and figure it out. Don't.

Honestly, this isn't our strength, and I'd rather tell you that now than take it on and do an average job. If it helps, here's what to look for in a team that does this well.

A clean no, said early, is remembered. The same person may come back later with something that is a fit.

3. Proposal and pricing

"Your quote is double what the other team quoted"

This is almost never a price conversation. It's a scope conversation. Two quotes for "the same app" are usually quotes for two different apps.

Don't drop your price on the spot. Ask to see what's in the other quote, or walk through what's in yours:

That's a fair question. Can we compare what's actually included? Ours covers the admin panel, testing on real devices, deployment and a month of fixes after launch. If theirs leaves any of those out, the gap closes quickly. If it doesn't, I'd genuinely like to know.

This is why your proposal should list what's excluded, not just what's included. "Not included: third-party API costs, content entry, App Store fees" saves you this argument later.

They want fixed price, but the requirements keep moving

The client wants a fixed number. Every call, the feature list changes.

Fixed price only works when the scope is fixed. If it isn't, one of two things happens: you eat the extra work, or you end up fighting about what was "included." Neither is good for the relationship.

Options that work better:

• Fix the price for the first milestone only, where scope is clear, and price the rest once it settles.
• Agree a fixed price with a written change request process: anything new gets scoped and priced separately before work starts.
• Move to hourly or a monthly retainer if the product is still being figured out.

Say it plainly:

A fixed price works when we both know exactly what's being built. Right now the list is still moving, which is normal, but it means a fixed number would either be padded or wrong. Here's what I'd suggest instead.

Proof that actually lands

A list of 15 past projects doesn't convince anyone. One project that solved the same problem they have does. Pick the closest match and say what was hard about it and how you handled it.

4. Nurturing

Great call, proposal sent, then three weeks of nothing

This happens more than anything else on this list. It rarely means no. Usually it means they're busy, waiting on someone, or comparing quotes and feeling awkward about it.

What we do:

• Day 3: a short nudge that makes replying easy. "Did the proposal make sense? Happy to jump on a 15-minute call if anything needs explaining."
• Day 8: add something useful. A thought on their idea, a risk you spotted, a similar project you've done. Not "just checking in."
• Day 15: ask directly. "Is this still on your list, or has the timing changed? Either answer is fine, it just helps me plan."
• After that: stop chasing. Leave the door open and move them to a monthly or quarterly touch.

The direct question in step 3 tends to get the most honest answers, because it gives them permission to say no.

A past client you haven't spoken to in a year

Their project paused halfway, or finished and they moved on. It feels awkward to reach out. It shouldn't. Past clients already know how you work, which makes them some of your best leads.

Don't open with "are you looking for development help?" Open with them:

Hi, was thinking about [product] the other day and wondered how it's going. Did you end up launching the booking feature? We've done some work recently on something similar and I had a couple of ideas, if you're interested.

Personal, specific, no pressure. If they reply, have a normal conversation first. The work comes up on its own.

"Budget isn't approved yet. Check back next quarter."

Put a reminder in the calendar and actually check back. Most people don't.

In the meantime, stay useful without asking for anything. Send them an article that's relevant to their market. Tell them when you ship something similar. When the budget does get approved, you want to be the first name they think of, not one of five they have to go and find.

5. Conversion and kickoff

"Let's just start, we'll figure out the details as we go"

The client is excited and wants to move. Paperwork feels like it's slowing things down. It's tempting to agree.

This is the most expensive sentence in client work. "We'll figure it out" means both sides will remember the conversation differently in two months.

You don't need a 40-page contract. You need four things written down and agreed:

• A short discovery summary: what problem we're solving and for whom.
• A scope document: what's being built, and just as important, what isn't.
• The SOW: milestones, payments, dates.
• How we work: who talks to whom, on which channel, how often, and how changes are handled.

Frame it as speed, not bureaucracy:

Totally with you on moving fast. Give me a day to put the scope on one page so we're both building the same thing. It'll save us a lot of back and forth later.

The contract is on Upwork, but the client wants WhatsApp

Very common. The contract and milestones live on Upwork, but day-to-day the client wants WhatsApp or Slack, because that's where they live.

Go with it. Clients should talk to you where they're comfortable. But decide upfront where decisions get recorded, because a WhatsApp thread is a terrible place to find out what was agreed six weeks ago.

Our rule: chat is for conversation, the written record is for decisions. Anything that changes scope, cost or timeline gets confirmed in writing in one agreed place, usually a short message or email that says "confirming what we agreed today." Milestone approvals stay on the platform.

Happy to use WhatsApp for day to day. For anything that changes scope or timeline, I'll send a quick written confirmation so we both have it in one place.

Set expectations on day one

In the kickoff call, agree:

• How often you'll send updates (we do daily)
• Who on their side can approve work and changes
• How fast each side should expect a reply
• What happens when something new is requested

Everything that goes wrong later is easier to handle if these were agreed when everyone was still in a good mood.

6. During delivery

They call it a bug. It's a new feature.

The client reports a "bug": the categories on their site can't be created dynamically by admins. But the scope said fixed categories. It was never built to do that, because nobody asked for it.

This one gets tense, because "bug" means "you owe me a free fix" and "feature" means "I pay more." Both sides feel they're being reasonable.

Don't argue from memory. Argue from the scope document, calmly:

I've checked this against the agreed scope. What we built works as specified: categories are set up by us, not by admins. Letting admins create their own is a new feature, and a good one. I'll scope it and send you the time and cost by Thursday.

The best fix is upfront. Define "bug" in the How We Work document before the project starts: something that doesn't work as described in the scope. Anything the scope doesn't describe is a change request. It's a lot easier to agree on this when there's no money on the line yet.

The requirements change halfway through the project

Six weeks in, the client comes back from user testing or an investor meeting and wants something different.

Don't treat it as a problem. Treat it as a new decision, and give the client the choice:

Makes sense, and better now than after launch. We have two ways to go: finish the current version as planned and take the new direction into Phase 2, or switch now. Switching means reworking about a third of what's built. I'll send both options with cost and timeline by Thursday, and you pick.

Until they pick, keep the team on work that's safe either way. Once they do, update the scope and dates in writing. Work already delivered to the old scope is still paid for.

If the change creeps in a little each week instead of all at once, the same rule applies. Stop and name it.

Eight small extras that nobody logged

Over two months, the team quietly did a lot of small things. A new field here, a tweak to the email template there, an extra export button. Each one took an hour or two. Nobody wrote any of them down, because each felt too small to mention.

Then the project runs over, or a dispute starts, and you realise you've given away a week of work with no record of it.

Log everything, even the five-minute stuff. Not to bill every item, but so you can choose. Sometimes you'll do it for free as goodwill, and that's fine, as long as the client knows it was goodwill:

Done. This one was outside the original scope, but it was quick so I've included it at no charge.

One line like that changes how the client sees the next request.

You're going to miss a deadline

You know on Monday that Friday's milestone will slip by a week. The instinct is to wait and hope you catch up.

Tell them now. The client can handle a delay. What damages trust is finding out on Thursday night. Give the reason, the new date, and if possible a choice:

Heads up: the payment integration is taking longer than planned because the provider's sandbox has been unreliable. We'll miss Friday. Two options: we ship everything else Friday and payments the following Wednesday, or we ship it all together next Friday. What works better for you?

A choice puts them back in control. That's most of what they need.

Fifteen change requests in one message, at 11pm

Don't start working on any of them, and don't reply to each one at length.

Acknowledge within 24 hours, group them, and scope them properly within a few working days:

Got all of these, thanks. I'll group them and come back by Wednesday with which ones fit the current scope, which are new, and what the new ones would take. Nothing changes on the current plan until you've seen that.

Then let the client prioritise. Often five of the fifteen turn out to matter.

The client goes quiet and you're blocked

You need sign-off on the designs, or their API keys, or content for the homepage. They've stopped replying. Your timeline is now their timeline, but they'll still remember the launch date you gave.

Put it in writing, with the date impact:

We're waiting on the homepage content to move to the next stage. If we get it by Tuesday, we're still on track for the 20th. After that, each day of delay pushes launch by about a day.

This isn't about blame. It's about making sure that when the date moves, everyone remembers why.

7. Handover

The project's done, but the "quick tweaks" never stop

Launch went well. A month later, the client is still sending small requests and expecting them done free, because in their head the project never really ended.

This is a handover problem, not a client problem. If nobody said when the project ends, it doesn't end.

Agree a support window before launch, in writing. For example: 30 days of bug fixes after launch, bugs meaning things that don't work as scoped. After that, new requests move to a retainer or a new phase. When the window is about to close, say so:

Quick note that the 30-day support window closes on Friday. Anything you spot before then, send it over and we'll fix it. After that, we can keep going on a small monthly retainer if you'd like us on call.

Their new in-house developer can't make sense of anything

The client hires their own developer. They open the codebase and send you twenty questions, half of which start with "why did you..."

A good handover pack prevents most of this:

• Full source code in the client's own repository
• All credentials and accounts transferred to the client (hosting, domains, app stores, third-party services)
• A README that explains how to run the project locally and deploy it
• A short architecture note: main parts, how they connect, and any decisions that look strange but were deliberate
• List of known issues and anything left unfinished
• A recorded walkthrough call
• Written sign-off that the project is complete

Offer one handover call with their new developer. It's an hour of your time, and it's the difference between "the previous agency left a mess" and "the previous agency was great to work with."

Make ownership clear

The client should own everything at the end: code, accounts, IP. If any account is still in your name, transfer it before you close. Nobody wants to discover a year later that their app store account belongs to an agency they no longer speak to.

8. After handover

They loved the work, but nobody asked for a review

The client was happy. Said so on the last call. Nobody asked for a review, and now they're busy with other things and it never happens.

Ask at the high point, not weeks later. The best moment is right after launch, or right after they say something nice:

Really glad it's landed well. Would you be up for leaving a short review? Even two or three lines helps us a lot. I can send you the link now.

Send the link in the same message. Every extra step loses people. While you're there, ask if you can write the project up as a case study, and whether they'd introduce you to anyone who might need similar help.

Phase 1 is ending, and nobody has mentioned Phase 2

Most products aren't finished at launch. There's almost always a list of things that were cut to hit the deadline, plus new ideas that came up once real users got in.

Keep that list during the project. Two or three weeks before handover, bring it up:

As we wrap up, here's the list of things we parked along the way, plus a few ideas from watching how people use it. Worth a call next week to talk about what makes sense for the next phase?

This isn't upselling. It's continuing a conversation they already care about. Starting Phase 2 with a team that knows the code is cheaper and faster for them than starting again with someone new.