Each project is a case: what it had to do, what made it hard, what I built, what it became. Click in for the long version — topology, decisions, results — not just a logo and a stack list.
Buy, sell and trade NFTs with an ML model that surfaces forward price signals. Every transaction settles on-chain so provenance and ownership stay tamper-proof. Capstone project at CUST.
An Emitter-style web app with Twilio voice underneath, so users dial from the browser straight to a phone line. Live SMS layered on top — the whole thing held together by a tight WebSocket layer.
A CRM with several teeth — accounting, sales pipeline, security staffing, and an ATIS complaint system. Each its own module, sharing one identity and audit layer. Backend integration owned end-to-end.
Full-stack engineer building the parts users don't see. APIs that don't fall over, microservices that talk to each other, payment rails, real-time voice/SMS over WebRTC, and the React Native frontends that ride on top.
{ "name": "Osama Hashmi", "role": "full_stack_engineer", "focus": ["apis", "microservices", "mobile"], "runtime": "node · nest · react-native", "deploy": "k8s · docker · aws", "replies": "~within 24h" }
// last 4 years, in numbers shipping_years 04 // since 2021 services_owned 07 // across 3 teams languages 06 // ts · py · rust · sol · go · js deploy_speedup −50% // k8s pipeline tuning system_efficiency +60% // at BufferSol realtime_scale +150% // at Web Stacking
Most portfolios list tools. I draw systems. Hover any node to see how it fits — from a React Native client all the way down to a Kubernetes pod running NestJS talking to Stripe and a Postgres replica.
Pick the boring tool that scales. Test the parts that move money or messages. Automate the deploy on day one. Below: a chronological log of what shipped.
Built a full-stack product on React Native + NestJS, deployed to Kubernetes. Owned the mobile client and the services it talks to end-to-end — auth, payments, push, plus the IDO‑CRM (accounting, sales pipelines, security staffing, ATIS complaint workflow).
Engineered a microservices architecture wired into Twilio Voice/SMS and WebRTC, routing real-time calls and messages between web users and phone lines. Containerised the lot with Docker, orchestrated on Kubernetes.
First production gig. Built interactive UI with React + Redux, profiled the client, and cut perceived load on the heaviest screens roughly in half.
From an NFT marketplace with on-chain provenance, to a Twilio-backed comms clone, to a CRM that quietly runs a security firm's back office. Click any card for the full case.
Buy, sell and trade NFTs with an ML model that surfaces forward price signals. Every transaction settles on-chain so provenance and ownership stay tamper-proof. Capstone project at CUST.
An Emitter-style web app with Twilio voice underneath, so users dial from the browser straight to a phone line. Live SMS layered on top — the whole thing held together by a tight WebSocket layer.
A CRM with several teeth — accounting, sales pipeline, security staffing, and an ATIS complaint system. Each its own module, sharing one identity and audit layer. Backend integration owned end-to-end.
Available for a long-running engagement where I can own a service end-to-end — backend, mobile, deploy. Short architecture or Twilio / payments consults also fine. Drop a brief over the fence.
Highlighted = primary tools — what I'd start a new system in tomorrow. The bar is intuitive frequency, not skill level. Everything listed I've shipped with.
I'm best on long-running engagements where I can own a service end-to-end — backend, mobile, deploy. Architecture and Twilio / payments consults also fine. Drop a note with what you're building.
Notes I write when something in production teaches me a lesson I don't want to forget. About boring choices, realtime plumbing, deploy pipelines, and the difference between shipping and shipping-shipping.
The Twilio docs are excellent, until you actually put load on the thing. Then you discover the bits the docs skipped. This is the missing manual.
Our k8s pipeline used to take 23 minutes from green tests to traffic. Now it takes 9. Here's the exact thing we changed, and what didn't help.
Four years of shipping React Native apps to real users on real devices. Here's the patterns I keep using on every new project, and the ones I quietly stopped recommending.
I've watched three teams burn a quarter trying to live on the bleeding edge. The fourth one — mine — picked Postgres, NestJS, and a boring CI pipeline, and shipped before the others finished their Helm chart. Boring is a feature.
I've watched three teams burn a quarter trying to live on the bleeding edge. The fourth one — mine — picked Postgres, NestJS, and a boring CI pipeline, and shipped before the others finished their Helm chart. Boring is a feature.
Every six months a new database, framework, or runtime shows up with a benchmark graph and a Twitter thread. The graph is real. The graph is also irrelevant for the system you are about to build. You are not Discord. You will not have a hundred million concurrent users by Thursday.
What you will have by Thursday is a deadline, two engineers, and an investor demo. The boring stack is the one where the answer to why is this slow is on Stack Overflow already, written by someone five years ago, who got it wrong, and someone else corrected them in the comments.
Postgres for almost everything that needs to be remembered. JSONB if you really need flexibility, but a real schema first. Node and NestJS on the API layer because I can hire for them and the patterns are codified. Redis for queues and cache. Docker because we already know it. Kubernetes only when the team is at least four engineers — otherwise a single VM with systemd will outperform your Helm chart for two years.
I am not against new things. I just want to spend my novelty budget on the product, not the runtime.
On one project we picked an exotic event-sourced store because the diagrams were beautiful. The diagrams stayed beautiful. The on-call rotation did not. We migrated to Postgres with an outbox table four months later and shipped the next feature the same week.
On another, we tried to put everything on serverless functions on day one. The cold starts ate the latency budget on a real-time voice product. We moved the hot path to a long-running NestJS pod, kept the truly stateless edges on functions, and the customer never noticed the migration — only the response times.
One novel piece per service. If the database is exotic, the framework should be familiar. If the framework is brand new, the database should be Postgres. Never two unfamiliar bets in the same blast radius. That single rule has saved me more weekends than any clever architecture.