I am a Senior Software Engineer in Dhaka, currently on SaaS platform engineering. This page is the short version of what I can be useful for.
Everything below starts with a message. Tell me what you are building, what is going wrong, or what you want to understand better.
Senior backend or platform engineering positions where reliability, delivery semantics, and operating cost are the actual problem. Strongest in Java and Spring Boot, C# and .NET, and event-driven systems on Azure and GCP. Having run 100+ technical interviews, I read a job description for what the team is short of rather than what sounds impressive.
Focused sessions for teams facing a decision they will have to live with: broker selection, partition and consumer design, CDC pipelines, service boundaries in .NET, or a migration that needs a rollback plan. Bring the constraints, not a finished design.
Hands-on sessions for engineering teams on distributed systems, messaging, and .NET architecture. Built from production experience and adjusted to what your team already knows, so nobody spends an afternoon being taught things they use daily. Eight of them are written up, problems and all.
Reliability before novelty.
I prefer well-understood tools, explicit guarantees, and designs that remain legible during an incident.
Trade-offs in writing.
A decision is easier to review when the constraint, rejected options, and cost are visible.
Operations are part of design.
Deployment, observability, recovery, and ownership belong in the first conversation.
Industries where the failure modes are real and the users notice. The about page has the company-by-company detail.
Multi-tenant B2B platforms, billing, entitlements, and the shared services behind them.
Payment rails, payroll platforms, and mobile financial services where correctness is not optional.
Production, inventory, and quality systems for global hardware and automotive programmes.
Clinical and operational software where downtime affects care, not just revenue.
Device fleets, telemetry ingestion, and the unreliable connectivity between them.
Most consulting questions arrive as something I have already written about. These are the four clusters that come up most, and the reasoning behind each answer is published rather than kept for a call.
Broker choice, partition strategy, consumer behaviour, replay, idempotency, schema evolution, and the delivery guarantees your application still has to implement itself.
What the runtime is actually doing while your code waits. Useful when a service is slower than it should be and the fix is not another layer of caching.
The unglamorous contracts that quietly break: time zones across regions, upload limits and streaming, and password storage that survives an algorithm migration.
Keeping knowledge authoritative instead of turning every repeated line into an abstraction, and knowing which cross-cutting helpers hide a dependency.
No forms, no qualification funnel. Describe the system or the problem and I will tell you honestly whether I am the right person for it, including who else you should talk to if I am not.