Running Client Conversations from Bangladesh, in English

Every engagement starts with a conversation I run myself, in English: what the client is actually trying to build, translated from a business goal into technical requirements before a sprint is ever scoped. I have run more than 50 of these at Exprovia, first call to signed scope, with the ambiguity resolved before a developer discovers it mid-build.

What happens when a client's requirements change mid-build is a communication problem before it is a delivery one. Two engagements asked for the same kind of thing in different shapes, and got different answers.

On a large-scale US civic information platform, the client's requirements outgrew what the platform could carry, close to launch. I priced the actual fix, budget and time both, and asked for exactly that: $1,000 and one month. The client agreed to both.

On an education platform, a client changed the build from single-vendor to multi-vendor mid-project. I asked for more time. They declined it outright, because the launch date mattered more to them than the schedule did, and offered more budget instead.

Same instinct behind both asks: name the real cost of the change and ask for it directly, rather than absorb the difference quietly. What differed was which lever the client actually had room to pull. One had both money and time to give. The other had money, not time, and said so plainly. Reading which one is actually on the table, before making the ask, is most of what makes a scope conversation land.

A client learns about a problem from me before they notice it themselves, or they do not learn it from me at all. When a developer's undisclosed implementation choice was going to surface as a slow admin page, I told the client the launch would be about an hour late, and why, rather than let them find it on their own. When a missed environment variable crashed a live site mid-migration, I called the client afterward and walked through what had happened; the client later praised how clearly it was explained, in English and in technical detail.

I work with US and EU clients daily: typically two or more hours of video-call overlap, plus six to seven hours available on chat, depending on how active the project is. Standups run async so a distributed team pays no meeting tax, and decisions are written where the team and the client can both find them, which removes the class of problem where two people remember the same conversation differently.