Let’s build software that survives production.
Tell me what the system has to do, and what happens when it does not. That second half is where the interesting conversation is - and it is the part most briefs leave out.
- Status
- Open to senior backend & platform roles
- Based in
- Dhaka, Bangladesh
- Timezone
- Asia/Dhaka · UTC+6
- Hours
- Sat - Thu, 9:00 - 18:00
One email is enough to start.
Thirty minutes is usually enough to work out whether there is something worth building together. Come with the problem rather than the solution - I will ask what breaks either way.
- What the system has to do
- What it currently does instead
- What happens when it fails
The questions that come up first.
Senior backend and platform roles, particularly anything touching payments, banking or systems where correctness under partial failure is the hard part. I am most useful on the services layer - the processes that have to keep working when a dependency does not.
Yes. I am based in Dhaka (UTC+6) and have worked with distributed teams and clients across timezones. Overlap with European mornings and Asian working hours is straightforward; US Pacific takes more deliberate scheduling, which is workable if the team is set up for asynchronous work.
Spring Boot and Rust are where I am heading - I use both daily on trade finance systems, and a stricter type system trades keystrokes for a class of bug that never reaches production. .NET Core and Node are where I have the most history. I care considerably more about the problem than about the language on top of it.
Selectively, and only where the scope is clear enough to be honest about. Payment integrations, backend architecture reviews and deployment work are the areas where I can add value in a short engagement without needing months of context.
Email within a day or two, usually the same day. If it is time-sensitive, say so in the subject line and it will get read first.