Full-stack developer & DevOps engineer who builds fast, reliable web apps

MedicsBD is a telemedicine service in Bangladesh. Patients book a doctor, pay with a local method, join a video call from their phone and get a prescription in Bangla. Agents in villages and garment factories book visits for people who can't do it themselves. The platform is live at app.medicsbd.com . The old version was a Laravel app: Blade templates, jQuery, Jitsi for video and a MySQL database that had grown to 64 tables. It worked, but it was slow to change and couldn't support a proper mobile app. In September 2026 I rebuilt the whole thing on a modern stack, moved every record across, and built native Android and iOS apps on the same API. What the platform does Patients find a doctor, pick a slot, pay, join the video call and keep their prescriptions, reports and health history in one place. They can add family members to their account. Doctors set their schedules, see today's queue, call patients, write prescriptions from templates and withdraw their earnings from a wallet. Agents (companies and remote field workers) register patients, book on their behalf and run a "kiosk" call from a shared device. Their commission is split automatically. Admins and desk doctors run the clinic from a dashboard: appointments, payments, withdrawals, users, packages, subscriptions, SMS and email templates, and reports. Factory and village programmes : worker lists with CSV import and QR invites, sick-leave certificates, lab orders, deliveries, health camps, SOS alerts, education sessions, complaints and daily HSE reports. The rebuild Stack. The web app is Next.js 16 with React 19, Tailwind and shadcn/ui. The API is Express 5 in TypeScript with Prisma and PostgreSQL, Redis and BullMQ for SMS, email and push jobs, and Socket.IO for chat and live notifications. One API serves the website and the mobile app. Video calls. Jitsi and Zoom were replaced with a self-hosted LiveKit server. When a doctor starts a call the patient's phone rings through a live notification, web push, and SMS as a fallback. There is a device check before every call and a kiosk mode for agents. Money. Payments go through aamarPay, PortWallet, manual bKash/Nagad/Rocket transfers or the user's wallet. Each paid visit is split between the doctor, the agent and the platform. I found and closed a race where a gateway redirect and its server callback could both confirm the same payment and pay the doctor twice. Every confirmation now "claims" the payment first, so it runs exactly once. Prescriptions. Doctors write prescriptions on screen and the same layout is printed to PDF with Puppeteer, the only reliable way I found to get correct Bangla text in a PDF from Node. Each PDF has a QR code that anyone can scan to check it is real. Codes printed by the old system still verify. Symptom checker. A public tool where you tap a body area on a male or female figure, pick symptoms (in English and Bangla), answer a few questions and get the likely conditions, how urgent it is and which doctor to see. The engine was ported from the old PHP code and checked against it result by result. A WordPress plugin embeds it and the doctor list on the main medicsbd.com site. Bangla first. All 1,200+ interface strings are in Bangla and English, the user's choice is saved to their account, and the fonts are chosen so Bangla and Latin text sit well together. Moving without breaking anything All 64 tables went from MySQL to PostgreSQL with a script that compares the row count of every table after the copy. Uploaded files moved to S3-compatible storage. Old password hashes still work, so nobody had to reset their password. Old links keep working too: doctor share cards and QR codes printed for clinics, store listing pages and the old admin and patient URLs all redirect to the right place. The older mobile app's API was rebuilt with the same responses, so people who haven't updated can still sign in. Before the switch I went through the old app's routes and permissions one by one, wrote a test matrix of role against endpoint (90 API tests), and loaded every page as every role to check for errors. That audit turned up real issues: discount codes that anyone could list, sandbox payment settings that would have stayed on in production, and reports that counted early-morning Dhaka visits as the previous day. The mobile app The Android and iOS app is built with Expo and React Native on the same API. Patients can book, pay through aamarPay (and come back to the app after paying), join calls, chat, read and share prescriptions, and delete their account. Doctors get their day's queue, can start calls, write prescriptions on the phone, and manage patients, schedules and their wallet. It has push notifications, an offline cache, a forced-update check and runs in Bangla and English, in light and dark mode. The Android build is 28 MB and opens in about a second. The app is finished and tested on real devices. It is waiting for the clinic's Google Play and App Store organisation accounts before release. Where it is now The new web platform is live at app.medicsbd.com . The screenshots show the public pages (sign-in, a doctor's profile, the symptom checker) and the patient, wallet, clinic and doctor dashboards from the live system, with patient names blurred. If you run a clinic, a health startup or any booking business on an old Laravel or PHP app that is hard to change, tell me about it . I can rebuild it, move your data safely and add a mobile app.

• Next.js 16
• React 19
• TypeScript
• Tailwind CSS
• +22

NETME is a Munich startup with a simple idea: fewer chats, more real meet-ups. You open the app, see who nearby is up for something, pick a café or bar and send an invite. No swiping, no matching. Local venues pay to be the place where those meet-ups happen. The product is five separate codebases that all talk to one API: the iOS and Android apps, the public website at netme.eu , a partner panel for venues and an admin panel for the NETME team. I joined in mid-2024 and since then I have worked on the API, both panels and the website. How the pieces fit together The app (iOS and Android): where users find people around them, send invites, chat and get reminders. It is the main customer of the API. The website (netme.eu): explains the app, sends people to the stores, and has a separate "Become a Partner" page that signs up restaurants, bars and coffee shops. It is in German and English. The partner panel (partner.netme.eu): a venue owner edits their profile and sees exactly how it looks in the app, books ads and push notifications, follows impressions, clicks and invites on a daily chart, prints their QR code and messages the NETME team. The admin panel (admin.netme.eu): the NETME team approves or rejects ads and push requests (with a reason the partner can read), manages partners, users, vouchers and subscription plans, and answers partner messages. The API: Node.js, Express and MongoDB. It handles invites, places, ads, payments, chat, notifications and the scheduled jobs that keep everything tidy. What I worked on Places. An invite needs a place you would actually meet someone. Place search goes through our own endpoint to the new Google Places API, results are filtered on the place's primary type so cafés, bars, restaurants and similar spots come up (not car parks or petrol stations), and a score puts the better options first. Distances between users are calculated on the server, not trusted from the phone. Ads that make sense for the user. A partner ad is only useful if it is near you. The ad query now uses MongoDB geospatial search inside a city-sized radius, removes duplicates between partner ads and external ads, and picks the ad each user has seen least that day, so one venue doesn't take every slot. Impressions and clicks are counted on the server, which is where the partner's dashboard chart gets its numbers. Rejected ads can be fixed and re-run without starting from scratch. Payments. Partners pay for their plan with Stripe (Starter, Business, Enterprise), and the partner panel locks paid features when a plan expires. App users buy premium through the App Store or Google Play, so the API verifies those purchases with Apple's and Google's servers before unlocking anything. A nightly job handles expiries. Messaging and notifications. Admin and partner messages moved to Firebase, with images, documents and inbox/outbox pagination. Both panels sign in to Firebase with a token issued by our API, so there is one login, not two. New ad requests, push requests and messages show up live in the panels over Socket.io, and the app gets push notifications through Firebase Cloud Messaging. Safety and clean-up. Rate limits on login, OTP and other sensitive routes, middleware that blocks scanner and bot traffic, stricter validation on social sign-in, and server-side encryption for uploaded files. When a user deletes their account, one service removes their data across every collection, and the panels show "deleted user" instead of breaking. Media that is no longer used is cleared out every night. Deployment. The API runs with PM2 on AWS EC2 behind Nginx, with a Docker setup for local work. GitLab CI runs the tests and a secret scan on every merge request and deploys main over SSH. Where it is now NETME is live in Munich. The apps are in the App Store and Google Play, and venues are signing up through the partner panel. The admin and partner panels are private, so the screenshots here come from a real partner account and the admin side. If you are building a location-based app, a marketplace with a partner side, or you need an admin panel for an existing product, tell me about it .

• React
• Redux Toolkit
• Chakra UI
• Ant Design
• +20

A self-hosted warehouse management system for a third-party logistics (3PL) business: one install runs several warehouses for several client companies, from the receiving dock to the truck, and each client only ever sees its own stock. The brief The goal was a WMS the business owns outright. It had to run on its own server, handle more than one warehouse and more than one client company from day one, and work with ordinary hardware: any keyboard-wedge barcode scanner and network Zebra label printers. No paid cloud service was allowed as a hard dependency. Carrier APIs, cloud storage and error tracking are optional add-ons, so the warehouse keeps working if a subscription lapses. The feature list was modelled on what the big platforms (Microsoft Dynamics 365, Oracle WMS, Manhattan) treat as basic: directed putaway, waves, license plates, replenishment, cycle counting, cross-docking, returns and labor tracking. A warehouse that has only "receive" and "pick" outgrows its software in a few months. What a normal day looks like in it Receiving: a truck arrives against a purchase order or ASN. The receiver scans each product on a handheld, enters lot and expiry where needed, and marks damaged units. The system creates a GRN and tells the putaway team which bin each pallet should go to, and why it picked that bin. Orders: client orders come in on screen or through the REST API. Stock is reserved and allocated with row locks, so two orders can never take the same units. Picking: orders are grouped into waves, and pick tasks are sorted in walking order through the aisles. Pickers get their next task on the handheld, scan the bin, scan the product, done. Packing and shipping: the packer gets a carton suggestion and a weight check, prints a Zebra label, and the shipment, manifest and bill of lading are produced from the same data. Supervisors watch it all on a live dashboard and a dark wall board on the warehouse TV, with an exceptions queue (short picks, full locations, damaged stock) that has owners and SLA timers. Clients log in to their own portal to check stock, orders, receipts and shipments, and pull their reports without emailing anyone. Three apps, one system The desk app is for office staff and supervisors: more than 60 screens covering master data, inbound, inventory, outbound, cycle counts, returns, 3PL billing, 16 reports and settings, with a Ctrl+K search that also accepts a barcode. The handheld app is built for gloved hands on a handheld scanner: one scan per screen, big buttons, loud error feedback, and actions queue up and sync when the Wi-Fi drops between racks. The client portal is a read-only window for each customer. The parts we were most careful about In a 3PL, the worst possible bug is one client seeing another client's stock. So the client filter is not something each screen remembers to add: it is injected into every database query by middleware, and a dedicated check script tries to break it. Stock can only change in one place in the code. Every movement is written to an append-only ledger (a database trigger refuses edits and deletes), balances are updated from that ledger, and a nightly job checks the two still agree. Quantities and money are fixed decimals, never floats. Database constraints refuse negative stock or allocating more than is on hand, even if the application code has a bug. Every change is in an audit trail linked by a hash chain, so you can tell if someone tampered with history. Double scans and double clicks happen all day on a warehouse floor. Every write carries an idempotency key, so the second one is ignored instead of receiving the same pallet twice. How it was tested There are 17 automated check suites. The most important one walks a real product through the whole warehouse over HTTP (receive, put away, allocate, wave, pick, pack, ship) and asserts that the ledger equals the balance at both ends. Another opens 84 screens in headless Chrome at handheld size and fails on any console error, failed request, sideways scroll or button smaller than a gloved thumb. We load-tested it with about 100,000 stock records and 130,000 ledger rows. The screenshots here are from a local run with demo data. Where it is now The software is finished and every check passes. The next step is user acceptance testing with real pickers on the warehouse floor, so it is not public yet. If you run a warehouse or a 3PL and want a walkthrough, get in touch .

• Next.js 16
• React 19
• TypeScript
• Tailwind CSS 4
• +13

StarVox is a multi-tenant SaaS dashboard where a business sets up an AI phone agent that answers every call, books appointments and logs each conversation. The brief The client wanted creating an AI telephone agent to feel like hiring an employee: answer five plain-English questions (what it should do, how it should speak, what it should know, which systems it connects to, which number it answers) and go live. Non-technical by default, with model and telephony settings tucked away behind an Advanced section. What I built I designed and built the whole web front end in Next.js 16 and React 19 against the client's real, deployed backend: around 110 API endpoints and no mock data. Every screen reads live data, and a screen whose API is not switched on yet says so instead of showing fake numbers. Dashboard: calls, voice minutes, bookings, missed calls, outcomes and a 7-day call chart. AI agents: greeting, system prompt, language and status, plus a Test call button that talks to the agent in the browser over LiveKit WebRTC. Voice picker: searches a catalog of 19,000+ ElevenLabs voices on the server, with language, accent and gender filters and one-click previews. Call history: recording, a turn-by-turn transcript, an AI summary and the details the agent pulled out of the call (date, time, party size, request type). Bookings and requests collected by the agents, ready for staff to action. Integrations: ERPNext, webhooks, WhatsApp (UltraMsg) and email, each with a test-connection button and a delivery log. Outbound campaigns: AI conversations or recorded voice broadcasts, with a do-not-call list. Self-service onboarding: sign-up, email verification, password reset, plan selection, Stripe checkout and a guided first-run tour. Super-admin area for companies, plans and billing across every tenant. Design and performance A custom purple/cyan brand system in Tailwind CSS 4 and shadcn/ui, in both light and dark mode. Motion is CSS-only (I dropped a JavaScript animation library that was slowing down page changes), fonts are trimmed to the weights actually used, every screen has its own page title, and only the public sign-in pages are indexable. Delivery Strict tenant isolation (the tenant comes from the login token, never from the browser), role-based screens for company admins and operators, and automated deployment from GitHub Actions to an Ubuntu server behind nginx.

• Next.js 16
• React 19
• TypeScript
• Tailwind CSS 4
• +9