A Node.js Developer's International Client Story: Expectations vs Reality

Twenty-three minutes. That is how long I practiced my introduction before the first Zoom call with a US client.

Alone in my room, talking to no one. I rehearsed how I'd explain my experience, what questions I'd ask about the project, how I'd handle it if they asked something technical I wasn't sure about.

The call lasted eleven minutes. The client asked three direct questions about my Node.js experience, I gave clear answers, they said "sounds good, let's start Monday," and that was it.

Not quite the dramatic moment I'd built it into.

What actually tested me was the seven weeks that followed.

---

How the project came in

My Upwork profile had been active for about eight months at that point. I'd completed three projects, all Indian clients, all small-to-medium scope work: a backend for an e-commerce site, a REST API for a mobile app, a database migration. Decent reviews. Rate around Rs 800 per hour.

Then an invite arrived from a US-based SaaS company. They needed payment integration added to an existing Node.js application. Six to eight weeks of work, they estimated. Rate: $18 per hour.

Honestly, my first reaction was suspicion. Client history on Upwork showed 47 hires, over $180,000 spent, average rating 4.9 across dozens of contracts. Real.

I sent a proposal. Two days later, the Zoom invite arrived.

---

Week one: the gap between expectation and reality

I had assumed an international client meant a cleaner project. Proper documentation, good test coverage, sensible architecture. Companies that have money to hire have money to maintain their code, right?

The codebase was four years old. Comments were sparse. Some of the architectural decisions only made sense after reading through old git commits to find context. The Express version was two major releases behind. Test coverage was close to zero.

I spent about three hours on the first day just trying to understand the structure well enough to know where to begin.

At the end of week one I sent the client a detailed message: here are three issues I found that need to be addressed before payment integration makes sense, here's why, here are screenshots, here's my estimate for fixing them (four to five extra days).

The reply: "Great catch. Go ahead and fix those first."

This felt like an important early lesson. Surfacing problems directly, with evidence, is almost always better than quietly working around them or saying nothing. The client appreciated the transparency. And I appreciated knowing they would respond that way rather than finding out later under worse circumstances.

---

Timezone: the practical version

California is thirteen and a half hours behind IST. In theory this seems manageable. In practice the gaps compound.

A blocker came up on a Friday evening my time, which was Friday morning their time. I sent a message. The reply came Monday morning their time, which was Monday evening mine. Four days gone for one clarifying question.

After that I changed one habit: any time something was unclear, I wrote down every question at once before sending anything. Five questions in a single message, not five separate messages over five days. The turnaround was one reply with five answers instead of five separate back-and-forths.

This sounds obvious. But when you're used to real-time communication with clients in the same timezone, the adjustment takes a few weeks to actually internalize.

For genuinely urgent things, I'd message on Slack during their morning hours rather than waiting for an overlap window. That worked well enough.

---

Scope creep: the first time I handled it badly

Week four. The client asked if I could "also add webhook support while I'm in there." Webhooks were related to payment integration but hadn't been scoped.

I said yes. Immediately. Didn't think about it.

I did the work. It took an extra four and a half days. The rate stayed the same. I said nothing.

Week six, a similar request came in. This time I stopped and wrote a careful reply: "This falls outside what we originally scoped. My estimate to add it is around X hours of additional work. Would you like me to include it with an updated agreement, or defer it to a follow-up phase?"

Their reply: "Let's keep it for the next phase. Focus on what we agreed."

Two things happened. The feature got deferred without any conflict. And I realized the week four situation was entirely avoidable. I'd just assumed raising the scope issue would feel confrontational. It doesn't have to. The way you frame it determines whether it's a negotiation or an accusation.

---

What the numbers looked like

Seven weeks. Total hours billed: 158. At $18 per hour, total: $2,844.

Converted at the rate at the time: roughly Rs 2,36,000.

For context, my previous three Upwork projects combined had earned me about Rs 31,000. This one project was almost eight times that.

The review was five stars. The comment included "will hire again."

Three months later they came back with a second project.

---

The honest part about what it actually takes

The technical skills were a given. You need to actually know Node.js well enough to work in an unfamiliar codebase without much hand-holding. That part was real. There's no shortcut around having genuine depth.

But the skills that determined whether the project went well had almost nothing to do with Node.js. They were: sending clear written updates without being prompted, recognizing when something was out of scope and saying so professionally, batching async questions to reduce the back-and-forth, and flagging problems early with evidence rather than hoping they'd go away.

None of that is taught in any course. You figure it out through friction.

The twenty-three minutes of preparation before that first call taught me nothing useful for the actual work. What taught me useful things was the uncomfortable moment in week four when I said yes to something I should have pushed back on.

And then doing it differently in week six.

That's roughly how the useful parts of experience accumulate. Slowly, and not on the schedule you'd prefer.