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.

Not every disagreement is about scope changing after a project starts. Sometimes it is about the client's own plan, arriving fully formed and detailed enough to look finished. On a pre-build architecture audit for a bilingual e-learning platform, a partner developer's client's own technical proposal held four assumptions that would not have survived the build: a deployment platform that could not run the application, a database that was not actually cost-efficient, an incomplete cost model, and one acceptance criterion the target platform could not meet.

I asked to raise all four in person rather than in writing, opened with everything I was accepting unchanged, and named my own side's earlier mistake before the client's. All four were accepted in the same meeting, and the timeline moved out rather than being protected at the plan's expense. The pattern holds across every disagreement on this page: name the real cost or the real risk specifically, and say it face to face before it becomes expensive to fix.

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.