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.
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.
TypeScript on day one, never retrofitted. Reanimated for everything that moves. A single navigation library across the app — I do not care which one, just one. Sentry on the very first commit, before there are any users. A real CI build that produces a real ipa and apk on every PR, not just on release.
EAS for builds. I used to fight my own Fastlane configs. I no longer do. The hours spent debugging code-signing on a Tuesday morning are hours that could have been spent shipping the actual product.
Heavy global state libraries on small apps. Most of the time, React Query plus a couple of contexts is the entire state layer you need. I keep watching teams reach for Redux on day one and end up writing more reducer than feature.
In-app web views for anything that should feel native. They always look great in the demo and feel wrong on a mid-range Android device with one bar of signal. Spend the extra week and ship native screens.
Set up over-the-air updates and analytics on day one, not when the first urgent customer issue makes it obvious. The cost of standing them up at the start is a single afternoon. The cost of standing them up during a Sev 1 is the entire day, plus your weekend, plus the trust of the customer.
After four years, the single biggest determinant of whether a React Native project goes well is not the framework, the state library, or the build tool. It is whether someone owns it end-to-end — design, mobile, backend, deploy — and can make trade-offs across the whole rope. That has been true on every project I've shipped.