I am a Senior Full Stack Software Engineer in Badda, Dhaka, Bangladesh. The products I work on hold the things companies argue about - money taken, stock sold, hours worked, messages sent - so most of my job is making sure those records are right even when a machine dies, a supplier fails, or two people act in the same second. I also build the interfaces people use and run the deployments, because the person who designed something should be the one who finds out it was wrong.
In practice that has meant a platform serving 10,000+ people a day without a bigger server, shop tills that keep selling through internet outages, and releases customers never notice. Below is how I work, how I got here, and the same experience described five different ways depending on which job title you were searching for.
Core stack: Python, Django, FastAPI, PostgreSQL, Redis Streams, Celery, pgvector, Docker, Traefik, AWS, Next.js, React Native, LangGraph, Scrapy, Playwright, Prometheus, Grafana, Cloudflare, PgBouncer, WebSocket.
Each of these cost me something to learn, and each has a business consequence. They show up in every system on this site.
Anything works when nothing goes wrong. The engineering is in deciding what happens when a machine dies mid-job, a supplier rate-limits you, or the same instruction arrives twice. Doing that up front is why my systems degrade into delays instead of into incidents - and why nobody gets a 2am phone call about them.
Anything that depends on a developer remembering a rule will eventually be forgotten, usually under deadline. So I put correctness where it cannot be skipped - separation enforced by the database, permissions that default to denied. The result is that the most expensive kind of mistake stops being possible rather than merely unlikely.
Order your checks by what they cost. Cheap ones absorb the volume; the expensive method only ever sees the small remainder that genuinely needs it. That is how a pipeline handles ten times the work without ten times the bill - and it applies equally to duplicate detection, permission checks and AI calls.
Link duplicates instead of deleting them. Redeploy the previous version instead of hot-fixing under pressure. Every threshold I have ever chosen was wrong the first time, so I make being wrong cheap to correct. Teams move faster when a mistake is a five-minute fix rather than a data-recovery project.
Language models are excellent at understanding what someone meant and unqualified to decide whether they are allowed to do it. Keeping that boundary sharp - a validated proposal, permission checks the model cannot bypass, a ceiling on how much one instruction can change - is what makes an AI feature launchable instead of permanently stuck in a demo.
Architecture notes, decision records and mentoring are not overhead. They are the difference between a system one person can run and a system a company owns. Practically, it means new engineers become useful in days, and no single resignation puts a product at risk.
Five years, described by what each step let me build rather than by the job title on the offer letter.
Four years that ended in a research thesis on translating between Bengali and English at the word level. It was my first real encounter with the gap between a model that works in a demo and one that works when other people depend on it - the gap I have been closing ever since.
Built the incubator's own platform while advising the startups inside it - shipping against requirements that changed weekly, which is where I learned to design for change rather than resent it. Began an MSc in IT at the University of Dhaka, carried alongside full-time engineering ever since.
Went from executing tickets to shaping systems in under a year: sitting with leadership while requirements were still vague, turning them into architecture, and owning the result across several products. Started leading junior developers, and started extracting the shared building blocks that made later projects cheaper.
Built the layer that reaches customers - email, push, SMS and WhatsApp - and the attendance engine that feeds payroll across multiple branches, replacing manual timesheet reconciliation. Added payments and sign-in through SSLCommerz, Stripe, Twilio and Google, so customers could pay locally or internationally.
Now removing what slows a product company down: breaking a monolith into services teams can ship independently, turning customer onboarding into an automated pipeline instead of a day of engineering time, and putting AI to work inside the development process. My Master's thesis is running in production as a real platform.
Job titles slice the same work differently, and a system does not care which one you use. Here is what I actually do, mapped onto the labels you are probably searching for.
One engineer, from the idea to the thing customers use.
Give me a business problem described in plain language and I hand back a working, deployed feature - the database behind it, the interface people click, the automation that runs overnight, and the release that puts it live. Fewer hand-offs means fewer misunderstandings and a shorter path from decision to revenue. Four products in production, three of them serving several customer companies from one system.
The part nobody sees, and nobody forgives when it is wrong.
Sales figures, attendance records, stock counts, payments - these are the numbers a business argues about. My job is making sure they are right when two people act at the same second, when a server dies halfway through a job, and when the same instruction arrives twice. Customers never notice this work; they only notice its absence.
AI features you can safely point at real customer data.
Most AI demos work once and fall over in production, because a language model is confident even when it is wrong. I build the boundary around it: the model suggests, the application checks and decides. That is the difference between a feature a company can actually launch and one that stays a prototype. My research background is NLP - a Bengali–English word alignment thesis - and my production work is making models behave like dependable software.
Release on a Tuesday afternoon, not at midnight.
Teams postpone releases because releases hurt - the site blinks, someone has to babysit it, and rolling back is a panic. I remove that cost. New versions go out while customers keep using the product, a bad build never receives traffic, and going back to the previous version is one command. Shipping stops being an event and becomes a habit, which is how features reach customers faster.
Work that still makes sense after I have left the room.
Software gets expensive when only one person understands it. I build so the opposite is true: shared building blocks that make the fifth feature cheaper than the first, architecture written down where the team can read it, and juniors coached until they can make the decision without me. The commercial version of that sentence is lower key-person risk and a shorter ramp-up for every new hire.
Both degrees were taken while working full time, and the research fed straight back into the products - the Master's thesis is running in production today.
IIT, University of Dhaka
Thesis (Project): Agentic Email Campaign Management Platform
North South University
Thesis (NLP Research): Bengali to English Word Alignment using Transformer based Multilingual-BERT
I read everything that comes in. If you are weighing a decision in this territory and want a second opinion - an architecture, a hiring brief, or a hosting bill that keeps growing - that counts as a reason to write.