Rates, time zones and communication with US clients

Thinking about a rate without a number to anchor on

A rate is a conclusion, not a starting point. It follows from a few things that are worth working out first: how senior the work actually is, how scarce that combination of skills is for this particular client, and how much of a scheduling or communication burden you take off their hands. Two specialists with similar technical skill can reasonably land in different places once you account for how much overlap, reliability and clarity each one brings to a project.

This guide will not give you a number, because the right one depends on your lane, your seniority and the specific client, none of which a general guide can know. What it can do is point at the factors worth thinking through before a client asks, so the conversation, whenever it happens, is not the first time you have considered them.

What seniority actually signals in this context

Years in a field are a rough proxy at best. What a client is actually trying to gauge is how much they can hand you without specifying every detail, how well you catch a problem in a spec before it becomes expensive, whether you can make a reasonable judgment call and explain it afterward instead of needing every decision confirmed first. Two people with a similar amount of experience can sit in very different places on that scale, which is part of why a rate benchmark tied to years alone tends to mislead more than it helps.

This is also why a track record that shows judgment, a hard tradeoff you navigated, a problem you caught early, a decision you made and explained, tends to do more work in a rate conversation than a list of technologies. A client weighing seniority is really asking how much oversight the engagement will need, and evidence of independent judgment answers that question more directly than a years-of-experience figure ever could.

Time zone overlap as a selling point, not an apology

It is tempting to treat a large time zone gap as something to explain away. A more useful framing is to state plainly which hours you can guarantee for calls, quick questions and same-day answers, and to treat the rest of your day as extended coverage rather than an absence. A client planning a project cares less about where you are physically and more about whether they know, in advance, when they can reach you and when a message will wait until morning.

We ask specialists for roughly four hours a day of overlap with a client's working hours, and we say up front which four before anyone agrees to anything. Stating a specific window like that, instead of a vague promise to be flexible, tends to read as more professional, not less.

What written communication actually needs to do

A US client who cannot see you day to day relies heavily on what you write. A short, regular status update, what moved since the last one, what is blocked, what is next, does more for a working relationship than a long report sent once a month. The goal is not length; it is predictability. A client who knows roughly when an update is coming and what it will cover worries less between updates.

• What changed since the last update, in plain terms
• Anything blocked, and what you need to unblock it
• What you plan to do next
• Any risk to a date the client is expecting

When a client asks for a number first

Some clients state a budget range before asking about your rate at all, which simplifies the conversation considerably; others ask you to name a figure first. If asked first, it helps to have already thought through the factors above, seniority, scarcity, overlap, rather than reaching for a number on the spot. A rate that is well reasoned and stated plainly tends to land better than one that is hedged, apologized for, or padded defensively because you were caught without having thought it through.

It is reasonable to ask a clarifying question or two about scope before answering, since a vague scope makes any figure close to a guess. Clients generally respect a specialist who wants to understand what they are pricing rather than one who names a number before knowing what the work actually involves.

What clients quietly grade you on

Technical skill gets you considered. What tends to decide whether a client renews or refers you afterward is quieter: do you answer messages within a reasonable window during a live sprint, do you flag a risk before it becomes a missed date rather than after, do you ask a clarifying question instead of guessing and building the wrong thing. None of this shows up in a portfolio, but it shows up fast in how a project actually feels to work with.

Clients remember how a project felt to run at least as much as what got built.