Open to remote software engineering roles

Muhammad Aqib · Full-Stack & Backend Engineer

Building reliable software for real-world problems.

I’m Muhammad Aqib, a software engineer focused on full-stack development, backend systems, and cloud infrastructure. I build maintainable applications designed for performance, reliability, and growth — and I care about what happens after they ship.

3+Years of professional software engineering
3Coordinated products in the Food Delivery platform
15+Technologies in regular, hands-on use
1Award of Excellence for production work at TurboDebt

Selected Work

Things actually built and shipped

A small number of projects, chosen for the engineering behind them — the problem, the architecture, and what my contribution actually was.

In developmentPersonal project · Full-stack platform

Food Delivery System

Designer & developer — backend, admin, and mobile app

A food delivery platform built as three coordinated products: a Laravel API, a React admin panel for restaurant and order operations, and a React Native customer app. The engineering focus is on the parts that usually break first — role-based access, real-time order updates over websockets, and queue-backed processing for work that shouldn’t block a request.

  • Laravel
  • PostgreSQL
  • Redis
  • React
  • React Native
  • Docker
Production · ~3 yearsTurboDebt · USA (remote)

Production Backend Systems

Software Engineer — APIs, integrations, infrastructure

Backend services for a US company’s production platform — the systems behind lead ingestion and day-to-day operations, plus the unglamorous work that keeps them alive.

  • REST APIs and lead-ingestion flows on PostgreSQL (AWS RDS)
  • Integrations with Salesforce, TrustedForm, and Jornaya — including token-refresh handling
  • Redis queues, Sentry monitoring, and single-point-of-failure reviews

Award of Excellence — presented by the Operations Manager at TurboDebt for production engineering work.

  • Laravel
  • Node.js
  • PostgreSQL
  • AWS EC2 & RDS
  • Redis
  • Salesforce API
In progressSkills build · Cloud & DevOps

Cloud & DevOps Practice

A staged, hands-on infrastructure build

Rather than collecting tutorials, I’m upgrading one flagship API project stage by stage — each stage adds a real layer of production infrastructure, with the trade-offs documented as I go.

  1. 01Linux & networking fundamentals
  2. 02Docker & CI/CD pipelines
  3. 03AWS deployment
  4. 04Terraform & infrastructure as code
  5. 05Observability & monitoring
  6. 06Kubernetes & Helm
  • Docker
  • AWS
  • Terraform
  • CI/CD
  • Linux
  • Kubernetes

Expertise

Three things I do well

Focused on the work I want to be hired for — not every tool I have ever opened.

Full-Stack Development

Complete products, from database schema to interface — admin panels, customer-facing apps, and the APIs that connect them.

  • React
  • Next.js
  • TypeScript
  • Laravel
  • Node.js
  • REST APIs

Backend & Data

API architecture, authentication and authorisation, database design, and the background processing that keeps systems responsive under load.

  • API architecture
  • Authentication
  • Database design
  • PostgreSQL
  • MongoDB
  • Redis
  • Performance

Cloud & Delivery

Deploying and operating software in production — and steadily deepening my infrastructure skills beyond the application layer.

  • AWS
  • Docker
  • Linux
  • CI/CD
  • Deployment
  • Monitoring

How I Work

From first sketch to steady operation

The same loop, whether it’s a client API or a personal platform: understand it, design it, build it in stages, then run it like it matters.

01

Understand

A working conversation about the problem, the constraints, and what “done” means in production — not just in a demo.

02

Design

API contracts, data model, and failure modes on paper first. Most expensive bugs are design decisions nobody wrote down.

03

Build in stages

Small, reviewable increments with tests around the risky parts — queues, payments, integrations — so progress is always shippable.

04

Ship & support

Deploy safely, watch it in production, and document the trade-offs. Software isn’t finished when it merges.

Consistency over heroicsDocumented processes and steady follow-through beat last-minute rescues — in code and in operations.

Measured, not guessedLogs, metrics, and honest reporting on what changed and what it’s worth, before opinions.

Own it end to endFrom the first schema to the 2 a.m. alert, the work has one accountable owner: me.

About

About me

I’m a software engineer from Multan, Pakistan. For around three years I built and maintained production software at TurboDebt, a US company, working remotely as part of its engineering team.

Most of my experience is at the backend and application level: designing APIs, modelling data in PostgreSQL, wiring up third-party integrations, and keeping queue-based systems running when a dependency misbehaves. That work taught me to care about what happens after deploy — reliability, observability, and code the next engineer can actually read.

I work in a Learn → Build → Break → Fix → Document loop, and I’m currently putting serious time into cloud and infrastructure: AWS, Docker, CI/CD, and the fundamentals underneath them. I’d rather understand a system properly than just make a feature work.

★★★★★

“Aqib was great to work with — and future employers would be fortunate to hire him.”

Matt Wenger · Former colleague, TurboDebt

Questions

Frequently asked

What kind of roles are you looking for?

Remote full-stack and backend software engineering roles with international teams — work centred on APIs, data, and production systems, where reliability and maintainability matter as much as shipping features.

Where are you based, and how do time zones work?

Multan, Pakistan (PKT, UTC+5). I spent around three years working remotely with a US company, so async communication, written updates, and scheduled overlap hours are my normal way of working.

What is your strongest area?

Backend engineering: API design, PostgreSQL data modelling, authentication, queue-based background processing, and third-party integrations — with React and Next.js on the front end when a product needs the full stack.

How do you approach an existing codebase?

Read first, change second. I map the architecture and dependencies, find the risky seams, then make small, reviewable changes — and document what I learn so the next engineer starts further ahead.

Are you open to contract or project work?

Yes — I am open to conversations about meaningful projects and technical collaboration alongside full-time roles. LinkedIn is the fastest way to start that conversation.

Contact

Have an interesting engineering problem to solve?

I’m open to conversations about software engineering opportunities, meaningful projects, and technical collaboration. LinkedIn is the fastest way to reach me; GitHub is where the code lives.