My First International Client: 3 Freelancing Lessons I Learned the Hard Way

My first international client was a first-time founder from Singapore who found me through a friend. The code was the easy part. The real lessons were about getting paid across borders, keeping the scope under control and learning which clients to be careful with. If you're a freelance web developer about to take your first overseas client, this is what I wish I'd known.
How it started
A friend gave my number to one of his contacts, who reached out, and we set up a call. He was starting his own business and needed a website.
From an MVP point of view, the idea seemed simple. As a finished product, it was much more complex. Something felt a little off, though. He didn't seem fully convinced by his own idea. He was still figuring it out himself.
I helped him narrow it down to a clear MVP, we agreed on terms, and I started working.
Normally I take an advance before starting. But because he came through a friend, I told him to pay whenever it suited him.
That was my first mistake.
Lesson 1: Set clear payment terms before writing a single line of code
The biggest mistake I made with this client was starting work without a reliable payment method or timeline in place.
He didn't have a clear way to pay me internationally. He kept asking for more time to sort out the payment process, and eventually told me he was having problems with his bank and needed even longer.
As a result, I didn't receive even the advance until the whole project was finished. The payment arrived a few days after I'd written all of the code.
In other words, I built an entire project before receiving any money.
Here's what I learned:
- Agree on payment deadlines before starting. Spell out exactly when the advance, milestone payments and final payment are due. Don't leave dates open to interpretation.
- Verify the payment method upfront. With an international client, make sure they can actually pay you through the agreed method before you commit to the project.
- Don't let their payment problems become yours. A client's banking issues may be genuine, but that doesn't mean you should fund their project with your time.
- Take an advance before starting work. An advance isn't just about money. It shows commitment from both sides and protects you from weeks of unpaid work.
- Pause if payment terms aren't honoured. If a client keeps missing agreed deadlines, stop and resolve it before investing more time.
The biggest takeaway is simple: never confuse a client's promise to pay with an actual payment arrangement. Verify the process, write down the terms, and make sure the first payment has cleared before you start.
Lesson 2: Define your deliverables and protect yourself from scope creep
My second mistake was not setting clear enough boundaries around what I had agreed to build.
I had already finished all of the code when the client came back and told me he no longer believed in the original idea and didn't want to pursue it.
Instead, he wanted a completely different website.
The new site wasn't hard to build, but that wasn't the point. It was a different project from the one we'd agreed on. I had already put in the time and delivered the agreed work, and I still agreed to switch to the new direction.
Looking back, I should have handled it differently.
Here's what I'd do now:
- Define the deliverables in writing. List the pages, features, functionality and integrations included. Avoid vague descriptions that can be read in wildly different ways.
- Include a change-request policy. Explain what happens when a client changes their mind, wants extra features or wants to replace the original idea entirely.
- Separate revisions from new work. Small tweaks to an agreed design are not the same as replacing the product. Make clear which revisions are included and which need a new quote.
- Agree on what happens if the project is cancelled. If a client abandons the idea after you've done substantial work, your agreement should say what they still owe.
- Don't feel obliged to take on a completely different project. You can renegotiate the price, timeline and deliverables, or decline the new scope.
In my case, the original project was already done, but I let the client change direction without renegotiating anything.
The lesson: a client's change of mind should not automatically become your unpaid extra work. If the requirements change significantly, stop, reassess the scope and agree on new terms before continuing.
Lesson 3: Never underprice yourself for promised future projects
This is one of the most tempting traps for freelancers, especially when you're starting out.
The pitch usually sounds like this:
"Pay me less for this project, and if it goes well, I'll bring you plenty of work in the future."
It sounds like a fair trade. You give up some income today for the chance of earning more tomorrow.
But there's a fundamental problem: future projects are promises, not guaranteed revenue.
With this client, I agreed to a lower price because I expected more projects to follow. I thought this one would be the start of a longer working relationship.
Those projects never came.
I had already delivered my work at a discount, and the future business never materialised. In the end, I underpriced myself for something that was never guaranteed.
Here's how I handle it now:
- Price the current project on its own merits. Your fee should fairly cover the work you're doing now, regardless of what might happen later.
- Don't treat verbal promises as guaranteed business. Without a concrete commitment, there's no assurance future work will arrive.
- Don't sacrifice today's earnings for hypothetical opportunities. If the client disappears after the first project, the original deal should still have been worth taking.
- Offer discounts on future work instead. If a client genuinely expects an ongoing relationship, reward the repeat business when it actually happens.
So instead of saying:
"I'll charge less for this project because you'll give me more work later."
Say:
"I'll charge my standard rate for this project. If you bring me more projects in the future, I'm happy to discuss a discounted rate for that work."
That changes the deal completely. You're paid fairly for today's work, and the client still gets a discount if the future business is real.
If a client wants a discount in exchange for a firm commitment to future work, you can also put it in writing, with defined minimums, timelines and consequences if those commitments aren't met.
None of this means every client who mentions future work is trying to take advantage of you. Some genuinely do bring repeat business. The mistake is treating that possibility as if it were already guaranteed.
Never underprice yourself for work that hasn't been agreed. Earn the right to offer a discount later instead of giving one away upfront.
FAQ
How should freelancers get paid by international clients?
Agree on the payment method before you start, and confirm the client can actually use it from their country. A bank transfer or an established international payment service is common. Most importantly, make sure the advance has cleared before you write any code.
How much advance should a freelance web developer take?
There's no fixed rule, but a meaningful advance before work starts, with the rest tied to clear milestones, protects both sides. The exact split matters less than agreeing on it in writing.
What should a freelance web development agreement include?
At minimum: the deliverables, the price, the payment schedule, the number of included revisions, a change-request policy and what happens if the client cancels midway.
Starting freelancing young taught me plenty too. Read how I earned my first ₹15,000 freelancing at 15. And if you're looking for a developer who's clear about scope and timelines from day one, tell me about your project.


