$ whoami
For founders and small teams with a live product and no dedicated ops person. Most engineers write the code or run the cluster. I do both — which means you don't hire twice, and nobody has to explain your system to a second person.
0+
Businesses running on a platform I architected
0.00%
Uptime on the production platform I operate
// the offer
For founders and small teams running a live product without a dedicated ops person. I ship features and keep production running — roughly 20 hours a month, on a monthly retainer.
Features, bug fixes, and code review. The roadmap keeps moving while the infrastructure stays boring.
Deployments, CI/CD pipelines, and infrastructure as code. Your environments get reproducible instead of hand-tended.
Monitoring, alerting, and log aggregation — so you find out from a dashboard rather than from a customer.
Incident response during an agreed window, and the runbook change that stops it happening twice.
Dependency updates, database migrations, certificate renewals, and backups you have actually restored from.
Written down here rather than discovered in month three. A retainer fails when the scope was never agreed.
Every system is different, so every retainer is scoped before it is priced. The first conversation costs nothing and you keep whatever comes out of it.
Get a free 30-minute infrastructure review// proof
Not a gallery. Each case study documents the architecture, the deployment topology, and the pipeline that puts it into production — so you can judge the work rather than take my word for it.
A multi-tenant booking platform whose engine is configured, not coded — one engine that models any booking, from a gallery ticket to a multi-hall cinema, because every schedule discretises into slots.
Confidential · 2025
Service management system for scheduling, fleet and resource management, request workflows, and financial tracking—delivered as a pnpm monorepo with FastAPI, React, and Expo.
Confidential · 2025
Mobile app and API for discovering and booking sports venues, with integrated payments and promotions.
Confidential · 2025
Backend API and async story pipeline for an AI-generated personalized story mobile app (Node, Express, Firebase, OpenAI, Runway).
Confidential · 2026
Backend for a mobile dream journal app—AI interpretation, TTS/video, symbols, and paywalled analysis and chat. Supabase (Auth, Edge Functions, Realtime, Storage), Prisma; Express API for local dev only.
// process
The same pipeline every time, from requirement to monitored production. Predictability is most of what you are buying: you should always know what is deployed, how it got there, and how to put it back.
Translate business goals into technical specs, scope, and trade-off decisions.
Model the data first — schemas, indexing, and access patterns that scale.
Choose the stack and design services, APIs, and integration boundaries.
Automate build, test, and release so every merge is deployable.
Ship to production on cloud-native infrastructure with zero downtime.
Close the loop with observability, alerting, and security hardening.
// judgement
Every engineer's CV says they mentor juniors and drive technical vision. Here is one real architectural decision instead — including the part where the technology got less credit than the rewrite did.
Counterfoil · rewrite a working system, or clean it up?
A Django monolith serving a hundred-plus operators at 99.99% uptime. Traffic was modest, so the problem was never scale. The problem was coupling: the code was tangled, and small bug fixes kept regressing major features. A change to a booking path would surface as a failure somewhere nobody was looking.
A small team, every engineer having lived with the product long enough to know what it actually did.
Cleaning up in place was argued seriously, and it is usually right. Rewrites are famous for failing, and a disciplined refactor would have prevented the next breakdown without paying for one.
Any decision that does not survive its strongest counter-argument was not a decision. It was a preference.
Rewrites fail for a specific reason: the people doing them do not understand what the old system does. That was not our situation. Every engineer carried years of domain context — the scarce ingredient a rewrite actually consumes — and user volume was low, so the blast radius of being wrong was small.
Those two facts made the risk acceptable, and neither is transferable advice. A team without that context should clean up in place.
The regressions almost stopped. But when I list what changed, the list is: more tests, clearer code splitting, monitoring across services. None of those three required microservices. All are available in a monolith to anyone willing to do the work.
What we got was a rewrite — the chance to build it properly with knowledge we did not have the first time. The rewrite fixed the coupling. The services divided the work. Conflating those two would flatter the architecture at the expense of the truth.
Not because it went well — plenty of decisions go well. Because the honest account of it gives the architecture less credit than the architecture would like. If I will tell you that about my own work, you can trust what I tell you about yours.
// who you're hiring
Head of Engineering at a New York based IT company, three years into the profession, and unusually comfortable on both sides of the deploy.
Most of my work is the unglamorous half of software: the Terraform that makes an environment reproducible, the GitOps controller that reconciles what is running against what was committed, the service account that means no static cloud credential is ever baked into an image. It is the half that nobody notices until it is missing.
The other half is product. I have shipped booking engines, field-service platforms, geospatial mobile backends, and LLM-powered pipelines behind real paywalls. Knowing how a feature will be deployed changes how you build it, and knowing what the feature is for changes how you run it. Splitting those two jobs across two people is where most of the cost hides.
I do fractional work alongside a full-time engineering role, which caps me at roughly twenty hours a month. That constraint is on the table from the first conversation — it is why the retainer is scoped the way it is, and why I would rather turn down work than quietly under-serve it.
Before the infrastructure work I did research — two peer-reviewed papers, on deep-learning tumour classification and on blockchain-backed transaction security. They are listed below. They have almost nothing to do with keeping your Postgres alive, but they are where I learned to be suspicious of a result I wanted to be true.
40%
Faster API responses after profiling and caching a backend that had grown slow under load
½
The onboarding time for new engineers, after replacing a wiki page with one-command dev environments
// research
N., Reza et al.
Lecture Notes in Networks and Systems, vol 729. Springer, Cham • 2023
DOI: 10.1007/978-3-031-36246-0_17N., Reza et al.
Lecture Notes in Networks and Systems, vol 853. Springer, Cham • 2023
DOI: 10.1007/978-3-031-50327-6_24// stack
Listed last, on purpose. Nobody buys Kubernetes — they buy a system that stays up. This is just the evidence that I can do the work above.
// before you ask
Answered here, so neither of us has to be polite about them on a call.
About 20 hours a month, worked evenings and weekends, Bangladesh time (UTC+6). Be clear-eyed about what that means: I already hold more than one engineering commitment, and a retainer is not a fourth job I quietly squeeze in. It is a capped, scheduled block. You would rather know that now than infer it in month three from how long I take to answer. If your system needs more than twenty hours a month of attention, I am the wrong person and I will tell you so on the first call.
Very few, and the arithmetic is the reason rather than the marketing. Twenty hours a month is one client's worth of real work. Anyone offering you a part-time retainer while carrying a full roster is either not doing the work or not sleeping, and both of those eventually become your problem.
Honestly: not much, until my working window. There is no pager and no 24/7 rotation — anyone promising you that for a part-time retainer is either lying or about to burn out. What I do instead is make 2am breakage less likely: real monitoring, tested backups, reproducible deploys, and a rollback that works. Production-down gets a response within four hours during my window, best-effort outside it.
If you have enough infrastructure work to fill forty hours a week, you should. Most teams with one live product do not — they have a few hours of real ops work and a lot of anxiety. A retainer covers the work without paying a salary for the anxiety. When you outgrow that, I will tell you, and I will help you write the job description.
You do, from the first commit. Everything I build for you — code, Terraform, pipelines, documentation — is yours on creation. If we stop working together I hand over credentials, docs, and a written summary of anything in flight. No hostage-taking, no lock-in, no consultant who is the only one who understands the deploy.
Month to month, 30 days notice on either side, no reason required and no penalty. A retainer that needs a lock-in clause to survive was not worth having.
We agree the extra time in writing before it happens, at an hourly rate set upfront. If it becomes a pattern, that is not a problem to paper over — it means the retainer is the wrong size and we should re-scope it.
Thirty minutes. Before we talk I look at what your system exposes publicly — deploy setup, TLS, headers, whatever CI you have in the open — and I bring you the specific things I would fix, in priority order. You keep that list whether or not you hire me. Nothing is scanned, probed, or touched that you have not published.
// start here
Thirty minutes, no charge, no obligation. I look at what your system exposes publicly, and I bring you the specific things I would fix — in priority order. You keep the list whether or not you ever hire me.
Send me a link to your product and one sentence about what worries you most. That is enough to start.
Reach out at nahidreza99@gmail.com
Or connect on LinkedIn.