HowIworkwithoverseasclients
Written scope before anything starts, a running demo every two weeks, and 3–5 hours of daily overlap with the UK, Europe and Australia. Here is the whole process, start to finish.
The short version
If you only read one section
I am one developer in Kathmandu, Nepal, working directly with founders and product teams in the UK, Europe, the United States and Australia. You get a written scope and a fixed price before any work begins, a demo of something running every two weeks, and a written update every week in between. Nepal Standard Time is UTC+5:45, so a normal working day here already overlaps three to five hours with a European or Australian one; for US clients I shift later and take calls in your morning. Code lives in your repository from the first commit, the IP is yours on payment, and thirty days of bug-fix support is included after launch. The first thirty-minute call is free, and if the project is not a fit I will tell you on that call.
Start to finish
The Six Stages of a Project
From your first message to thirty days after launch. Nothing here is aspirational — it is how every project on the case studies page actually ran.
You send a project brief
Day 0Email, WhatsApp or the contact form — whichever is easiest. A few sentences on what you are trying to build is enough; you do not need a specification. If you already have designs, an existing codebase, or a competitor product you like, send those too and my first reply can be a real answer instead of a round of questions.
I reply within 24 hours
Within 1 working dayYou hear back from me, not a sales team. The reply covers whether I think the project is a fit, the questions I still need answered, and a rough shape of the work where I have enough to give one. If it is not a fit, I say so here rather than three weeks later.
A free 30-minute discovery call
Within a few daysGoogle Meet or Zoom, at a time that works in your timezone. I ask the awkward questions early — who the users actually are, what happens if the deadline slips, what the budget really is — because those are the things that derail projects at week eight. If the overlap is tight we can do this asynchronously in writing instead and save the call for when we are aligned on the basics.
A written scope and fixed quote
Within 48 hours of the callNot a one-line estimate. You get a document listing the deliverables, what is explicitly out of scope, the milestones with a payment gate on each, the delivery date, and the price. Nothing starts until you have read it and agreed to it in writing. This is also where the NDA and IP terms are settled.
Build, in two-week sprints
Weeks 1 to launchEvery sprint ends with a demo of something that runs — not a status slide. Between demos you get a written update once a week, including the weeks when nothing is broken, so you are never guessing. Anything that would move the date or the price gets raised, priced and agreed before I build it.
Launch, then 30 days of cover
Launch + 30 daysApp Store and Play Store submission where the project needs it, deployment and CI/CD set up in your own accounts, and a handover walkthrough of the codebase. Thirty days of bug-fix support is included after launch. If you want ongoing work after that, a monthly retainer covers 10–20 hours a month.
The timezone question
When Our Working Days Overlap
Nepal Standard Time is UTC+5:45 and I work Sunday to Friday, 09:00–18:00. That is not a detail I gloss over — here is exactly what it means for your working day.
United Kingdom
3–4 hoursLondon · GMT / BST
My working day covers your 09:00 to roughly 12:15–13:15.
Central Europe
4–5 hoursBerlin, Amsterdam, Paris · CET / CEST
My working day covers your 09:00 to roughly 13:15–14:15.
Australia
3–4 hoursSydney, Melbourne · AEST / AEDT
Your afternoon, from roughly 13:15–14:15 until you finish.
United States
3 hoursNew York, Chicago · ET / CT
By arrangement I work the Nepal evening, which lands 09:15–12:15 in US Eastern — your morning.
The honest version: a Nepal working day and a US working day barely touch, so for American clients I move my hours rather than pretend the problem away. The more useful point is that almost none of the work needs us both awake. The weekly written update and the fortnightly demo exist so that progress does not depend on finding a meeting slot — and I have run projects this way with clients in Australia, the United States, the United Kingdom and Germany.
Communication
Cadence, Tools & Language
Async by default, so nothing waits on a shared calendar slot.
- Written updates
- Notion, once a week, whether or not anything went wrong. Includes what shipped, what is next, and anything I am blocked on.
- Demos
- A live walkthrough of a running build every two weeks, recorded if you cannot make the time.
- Day-to-day questions
- Email or WhatsApp. I answer within 24 hours, usually the same working day.
- Calls
- Google Meet or Zoom, scheduled in your timezone rather than mine.
- Code
- Your GitHub repository, with CI/CD through GitHub Actions. You can see every commit as it lands.
- Language
- All work, documentation, code comments and calls in English. Nepali is my first language; English is the language I have worked in professionally for over five years.
Both directions
What You Get, What I Need
A project goes wrong far more often from a slow decision than from a hard technical problem, so this half matters as much as the other.
What you get, every project
- ✓A written scope and fixed quote before any work starts
- ✓A running demo every two weeks
- ✓A written progress update every week
- ✓Milestone payments, so you never pay far ahead of delivered work
- ✓Your repository, your deployment accounts, your IP
- ✓30 days of bug-fix support after launch
What I need from you
- ✓One decision-maker I can ask questions of, not a committee
- ✓A reply within a couple of working days when I am blocked on a decision
- ✓Access to whatever exists already — designs, codebase, analytics, accounts
- ✓Honesty about the real budget and the real deadline, early
- ✓Sign-off on scope changes in writing before I build them
How long things take
Typical Timelines
Real ranges from work already delivered, not best-case marketing numbers. Your project gets a specific date in the scope document — I do not guess.
1–2 weeks
Landing page or marketing site
3–5 days
App audit and code review
4–8 weeks
Django backend or REST API
6–8 weeks
Flutter app MVP, both stores
6–10 weeks
AI / ML model integration
8–14 weeks
Full-stack web platform
For a worked example: the GymTaar fitness platform — a Flutter app with live video calling, a Laravel backend and submission to both app stores — went from empty repository to the App Store in nine weeks. Full costs for each project type are on the pricing page.
The questions overseas clients actually ask
FAQ
Most of the work does not need us both online. You get a written update every week and a demo every two weeks, so progress is visible without a standing meeting. For the calls that do matter — kickoff, sprint demos, anything contentious — I move my hours to suit you. Nepal Standard Time is UTC+5:45, which gives 3–4 hours of same-day overlap with a London or Sydney working day and 4–5 with Central Europe. For US clients I start later and take calls in the Nepal evening, which lands in the US Eastern morning.
I do. There is no agency layer, no account manager, and no junior developer the work gets passed down to. You talk to the person writing the code, which means answers about the codebase come back in one hop instead of three. The trade-off is honest: I am one person, so I take on fewer projects at once and I will tell you if your timeline needs more hands than I have.
Fixed-price projects are split across milestones, so you are never paying far ahead of delivered work. Invoices are in USD and I accept international bank transfer and Wise. Payment terms are written into the scope document before work starts, alongside the deliverables and dates.
You do, on final payment for each milestone. The repository is yours from day one — I work in your GitHub organisation where you have one, or transfer ownership at handover where you do not. I keep no rights over client work beyond naming the project as something I built, and I will drop even that if you would rather I did not.
Yes. Send me yours, or I will send a simple mutual NDA — either way it is signed before any detailed scope conversation. Mention it in your first message and I will have it over to you the same day.
Everything is set up so you can. Typed TypeScript on the frontend, BLoC architecture in Flutter, a README that explains how to run the project locally, and CI/CD through GitHub Actions so the deploy path is in the repository rather than in my head. The point of the fortnightly demo is that you are never more than two weeks from a working build you understand.
It usually does, and that is fine. Small changes get absorbed into the current sprint. Anything that moves the delivery date or the price gets written down, priced, and agreed before I build it — you will never find out about a cost at invoice time. I will also push back when a requested feature will cost weeks for little user benefit; two of the three clients quoted on this site mention that as the reason they kept working with me.
Yes — a 30-minute call, no charge and no obligation. If it becomes clear the project is not a fit for me, I will say so on that call rather than send a quote I do not believe in.
Next step
Start with the free call
Thirty minutes, no charge, no obligation. Bring a rough idea and leave with an honest view of what it takes to build. If you would rather read more first, the case studies show the work, client feedback covers what it was like to work with me, and my background covers who you would be hiring.