Rasel Mridha: Technical Project Manager with a Full-Stack Engineering Background

A project manager who cannot read the codebase runs on a translation layer. Every estimate arrives pre-interpreted, every risk arrives pre-summarized, and every "this needs two more weeks" has to be accepted or challenged on trust, because there is no independent way to check it. That dependency is invisible while a project is healthy and expensive the moment it is not.

The opposite gap is as common and gets discussed less. An engineer who can read every line in the repository often has no mechanism for holding scope when a client asks for a block of new features late in a program, no hiring pipeline when the team has to double, and no habit of telling a stakeholder that a date is at risk before the date is missed.

I work across that gap, and the difference shows up during a bad week. When a Facebook campaign spiked concurrent users to 20,000 against an estimated 8,000 and login started timing out, I did not wait for a status page or a vendor to explain it. I traced it myself to cross-region latency between the database and the application, and moved the platform to an AWS backup that already existed for exactly that situation. The move took about 30 minutes. The client got a cause and a fix in progress within the hour, not an apology and a guess.

That is the argument of this page. The engineering background is not a second service on offer. It is the reason the delivery decisions get made against evidence instead of relayed opinion.

The progression is documented rather than claimed. Web developer, internship, remote, March 2025 to May 2025. Full stack web developer, on-site, May 2025 to August 2025. Associate project manager, on-site, August 2025 to February 2026. Project manager, on-site, since January 2026. One company, Exprovia, in Rajshahi. Total tenure 1 year 5 months. Exprovia is also the first job: there is no earlier employer behind this record, and no role missing from the timeline. It is also where the client-facing side of the role started: running discovery, scope, and risk conversations directly with clients outside Bangladesh, in English, from the first onboarding call onward.

Four roles in 17 months is fast, and the fair question is whether the practice is deep or only quick. The answer I can evidence is the record those roles produced: 50+ client onboardings run directly in English, an engineering team taken from 7 to 20, and 8 delivery incidents documented end to end, each one carrying the decision made, the option ruled out, and what the choice cost.

The engineering work is not a parallel offer. It is the reason the project management is not run on translation. I wrote the kind of code I now schedule, and the estimates I hold teams to are the kind I have had to make myself.

During a Vercel-to-AWS migration, a missed environment variable crashed the live site while a client campaign was already driving traffic to it. Reading the deployment logs directly, instead of waiting for someone to summarize them, is what let me rule out a rollback and apply the actual fix in 35 minutes.

A payment gateway went down mid-launch and stayed down for about four hours. A fallback path and a manual recovery tool already built into the admin panel meant every stuck payment got processed by hand, and none were lost.

Day to day, reading the code changes four things. I weigh architecture decisions instead of ratifying them, against the load profile and the query plan rather than the loudest argument in the room. I size effort against the actual repository, which is most of why milestone dates hold. I mentor developers directly instead of routing coaching through a lead. And I can call feasibility in the room, with the reason attached, which lands better than "the team says no".

Turn the business goal into scope and dates. Every program begins by converting what the client is trying to achieve into sprint scope and milestone dates, so every ticket traces back to the outcome it serves. That mapping is also what makes scope defensible later. When a client asked for a block of new features late in a program, I ran a scope review with the original agreement and the new requests side by side, each carrying its impact on the committed dates, and negotiated a phased plan rather than refusing it or absorbing it quietly. The client accepted it: the phased plan delivered on time, and the added budget was explained against the specific scope and upgrade work it covered.

Build the system the team runs on, not the ticket queue. Taking a team from 7 to 20 is a systems problem before it is a hiring problem: the onboarding path, the delivery process and the mentoring structure have to exist before the people arrive, or each new hire slows the existing team down. The same instinct applies under pressure. When a 4-person team's velocity dropped 40% mid-sprint, I sat with each developer individually instead of raising it with the group, because the cause was different for each of them: a cross-team rate-limit mistake, and less experienced developers taking complicated paths through problems that had simpler ones. Velocity recovered in about four days.

Stay in the code the team ships. In practice that means reviewing pull requests, holding an opinion in architecture discussions, and being able to tell whether a number is a people problem or a process problem before the team acts on it.

The speed of a recovery is usually a function of what was built before the incident, not what was decided during it. A bKash fallback and a manual recovery tool in the admin panel already existed before a payment gateway went down mid-launch. An AWS backup was already built before a campaign spiked traffic past what the primary setup could hold. Three separate monitoring layers were already wired up before a missed environment variable crashed a live site mid-migration, and each one was watching for something different: an email alert on every deployment, ECS's own crash monitoring, and UptimeRobot watching the site independently. That redundancy is why it was caught at two in the morning instead of by a customer the next day. All three examples looked like fast thinking under pressure while they were happening. All three were actually preparation that happened earlier, and the only thing left to do during the incident was use what already existed.

The client hears it from me first. When a milestone slips or a system fails, the client learns it from me before they notice it themselves: in a scheduled call, in English, with what happened and what changes next. An escalation is almost never about the failure. It is about finding out late. That is why I told a client directly that a launch would be about an hour late, and why, and why I called a client myself after a 2 a.m. deployment failure to walk through what had happened rather than let the fix speak for itself.

Project intake ran through a form, a hand-typed ClickUp task, a hand-written project document, and a manual developer handoff: the same repetitive steps on every new project, regardless of how busy the week already was. I automated the purely mechanical part myself: a form submission now creates the ClickUp task automatically. For the document, I put an LLM on it, because writing that document was never transcription; it meant reading what the client actually needed and organizing it into instructions a developer could act on, which is interpretation, not template filling.

What I did not automate is the judgment. What the model drafts does not go straight to a developer. I review it myself, record a video brief from it, and only then assign the work from Telegram, which creates the ClickUp assignment and notifies them. That review step is not a gap in the automation, it is the design. Roughly 30 minutes saved per project intake, by estimate rather than a tracked number, with dependency-related delays down roughly 20%.

I am based in Rajshahi, Bangladesh, and I work remotely with clients inside and outside the country, typically with at least two hours of video-call overlap each day and six to seven hours available on chat, depending on how active the project is.

Distributed delivery fails in predictable ways, so I run it against those failures. 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 scope conversation differently. Status is visible rather than requested: shared dashboards for scope, risk and delivery state, so a stakeholder never has to ask in order to know. Standups are async and daily, because a team spread across schedules cannot afford a meeting that only works for one time zone.

During incidents the response is only as fast as what was already built before them. A campaign once spiked traffic past what the primary setup could hold, and moving to a backup already built for exactly that situation took about 30 minutes. Clients rarely escalate over a problem. They escalate over silence during one, and a cadence they can see is what prevents that.

For a platform whose requirements outgrew what it was originally built on, the repair was structural rather than apologetic: a renegotiated budget and timeline, and an architecture that gave the platform room to grow instead of a patch that would not have held. It launched, and the client is now building mobile and iOS apps on the same platform.

Exprovia's leadership is working toward a team of 200+ by 2027. My part is the delivery structure that a team that size needs: onboarding, mentoring, and the internal operations, which I currently run.