Loading…
MostafijurRahaman
Software architect · backend platform engineer · SaaS product builder
I build reliable platforms, useful products, and stronger engineering organisations.
I lead architecture and engineering for high-traffic platforms, turning complex operational problems into scalable, reliable products.
10+
years building software
~2M
daily requests
99%+
platform uptime
~37%
cloud infrastructure cost reduction
Reduced cloud infrastructure costs by approximately 37%.
Work
Selected work
Platform Engineering
Dr.Job — High-Traffic Recruitment Platform
Lead Backend and Platform Engineer
How I led backend and platform changes that improved availability, latency, delivery safety, and infrastructure efficiency on a live recruitment platform handling approximately two million daily requests.
~2M daily requests · 99%+ uptime · ~37% infrastructure cost reduction
SaaS Product
ScholaBook — School Management Platform
Product Architect and Lead Engineer
How I designed and built an admin-first SaaS platform for private schools to manage fees, student records, attendance, examinations, communication, and day-to-day administration from one system.
Active product
SaaS Product
WPVite - Managed WordPress Automation Platform
Product Architect
How I designed a managed WordPress platform that turns a curated template into an isolated, configured site by coordinating hosting, DNS, storage, WordPress automation, and secure administrative access.
Private beta
Writing
Ideas
Modernising a High-Traffic Laravel Monolith Without Disrupting Production
A practical approach to evolving a busy Laravel codebase: reduce risk first, extract only when the boundary is real, and keep production operable throughout.
Designing Notification Systems That Survive Real Traffic
Notifications look simple until retries, fan-out, preferences, and provider failures show up. Here is a durable mental model for building them as an operable subsystem.
How I Think About Engineering Quality, Delivery Speed, and Technical Debt
Quality, speed, and debt are not slogans. They are competing constraints. Here is a practical way to negotiate them without pretending trade-offs do not exist.
Beliefs
Principles
A path that survives production load, operations, and change is more valuable than a polished demo that only works on the happy path.
Most of the risk in backend and platform work shows up after the first demo: traffic patterns, failure modes, deployments, and the cost of changing the system later. I bias toward designs and delivery choices that stay operable—observable, recoverable, and evolvable—even when that means a slower first screenshot.
Engineering decisions are easier to trust—and revisit—when constraints, options, and what you gave up are stated plainly.
Hidden trade-offs create false confidence. Teams and future-you need to know what was constrained, what was rejected, and why the chosen path won. I treat constraints and trade-offs as first-class narrative in case studies and reviews, not as footnotes after the architecture diagram.
End-to-end ownership—from framing the problem through architecture, delivery, and production care—beats handoff theater.
Reliable platforms and products improve when someone stays accountable across the whole path: context, design, shipping, and what happens after launch. That ownership can be shared across a team, but it should not dissolve into unclear handoffs where no one owns outcomes.