Case Studies

How I Solve Problems

Not just what I built — how I built it and why. Deep dives into real production challenges, the decisions behind the code, and the lessons learned.

Case Study #1

Senior Backend Engineer

Ongoing

How I Built a Money-Safe Escrow Payment System

TrustBrig — Multi-Currency Escrow Marketplace (USA)staging.trustbrig.com

NestJS

TypeScript

PostgreSQL

Buckzy (BaaS)

Double-entry Ledger

Redis

Socket.io

TrustBrig is a multi-currency escrow marketplace for a US client — a platform where strangers can transact safely across currencies and borders. A buyer's funds are held in escrow and released to the seller only when deal conditions are met. The hard part isn't the UI; it's moving real money without ever losing or double-paying a cent, on top of a Banking-as-a-Service rail (Buckzy) that only exposes a single pooled balance.

The Challenge

1Real money across 6+ currencies with escrow holds — a single lost or doubled transaction is catastrophic and hard to unwind
2The payment provider shows one pooled balance and has no return webhooks (email only) — the platform must own the source of truth and all safety logic
3Provider webhooks are unsigned and can arrive twice or out of order — they cannot be trusted blindly
4Funds must not be withdrawable before settlement is final (ACH/wire return windows), or the platform eats the loss
5Users must not be verified twice (KYC), and dispute outcomes must move money correctly (refund / partial / release / split)

The Approach

Double-Entry Ledger as Source of Truth

Built an internal double-entry ledger (integer minor units, balanced-at-commit) as the authority for who owns what — never the provider's pooled balance. Every movement is two balanced entries, append-only and auditable.

Transactional Outbox

No payment API is ever called inside a user request. State changes write a ledger journal and an instruction row in the same DB transaction; a worker dispatches it after commit — so a crash can never lose or duplicate a money move.

Idempotent, Verified Webhooks

Every external call carries an idempotency key; every inbound webhook is deduplicated and confirmed-by-GET before acting (the provider's payloads are unsigned). Retries can never double-charge or double-pay.

Escrow Engine + Settlement Gating

Standard and milestone escrows with hold/release/refund, inspection windows, auto-release timers, and mutual cancellation. Withdrawals are gated behind settlement finality so money only leaves once it's irreversible.

KYC Reliance, Disputes & Step-Up Auth

Integrated KYC (Didit) with a reliance model so users verify once; built dispute resolution & mediation with money-correct outcomes; and added step-up re-authentication (2FA/passkeys) for every fund-moving action.

The Results

Double-payments (by design)

2-way

Ledger vs provider reconciliation

80+

Payout countries (rail)

Currencies + stablecoins

Integrated the Buckzy BaaS rail end-to-end — wallets, funding, FX, account-to-account transfers, and global payouts — verified live in sandbox
KYC reliance model (Didit) so users complete verification only once
Dispute resolution & mediation with refund / partial / release / split outcomes
Step-up re-authentication (2FA / passkeys) and RBAC on all money actions

Key Takeaway

“Moving real money is a discipline, not a feature. The ledger — not the provider's balance — is the source of truth. Idempotency, a transactional outbox, and reconciliation turn an unforgiving problem into a reliable, auditable system.”

Case Study #2

Full Stack Developer

6+ months

How I Migrated 2 Billion Records Without Losing One

PakPassion — Legacy Forum to Modern Stackforum.pakpassion.com

Node.js

Express 5

PostgreSQL

BullMQ

Redis

Socket.IO

Knex

PakPassion is one of the largest cricket community platforms — 62K+ registered members, 162K+ threads, and over 2 billion posts accumulated over 15+ years on legacy XenForo (PHP/MariaDB). The client needed a complete platform modernization without losing a single record or disrupting the community.

The Challenge

130GB MariaDB database with 2B+ rows across deeply nested tables — posts, threads, users, attachments, permissions, all interconnected with foreign keys
2Legacy XenForo schema used serialized PHP objects in database columns — not standard SQL types, making direct migration impossible
3The forum had to stay live during migration — zero downtime tolerance, the community posts constantly
4No existing migration tooling existed for XenForo-to-PostgreSQL at this scale — everything had to be built from scratch
5Data integrity was non-negotiable: broken thread chains, orphaned posts, or lost user data would destroy years of community history

The Approach

Schema Analysis & Mapping

Spent 2 weeks reverse-engineering the XenForo schema. Mapped every table, serialized field, and relationship. Designed a new PostgreSQL schema with proper types, indexes, and constraints — 83 migration files total.

Resumable Migration Pipeline

Built 40+ migration scripts with BullMQ workers. Each script tracked its own progress in a separate state table — if the process crashed at row 1.5 billion, it picked up exactly where it left off. No duplicate inserts, no gaps.

PHP Serialization Decoder

Wrote a custom Node.js parser to decode PHP serialized objects stored in MariaDB columns. Converted them to proper JSON/PostgreSQL types. This alone handled ~200M rows of serialized data.

Batch Processing with Backpressure

Processed records in configurable batches (5K-50K rows). BullMQ workers with concurrency controls ensured the source database wasn't overwhelmed. Redis tracked progress in real-time.

Integrity Verification

After migration, ran automated count verification (source vs. destination) across every table. Cross-checked foreign key relationships, thread chains, and user associations. Every number matched.

The Results

2B+

Records migrated

Records lost

40+

Resumable scripts

DB migrations

Built real-time chat system on top — DMs, read receipts, typing indicators with Socket.IO + Redis Pub/Sub
FCM push notifications for instant mobile alerts
Two-layer RBAC with shadow bans, IP blocking, and per-space moderation
2FA with TOTP + QR codes + backup codes

Key Takeaway

“The key insight: migrations at this scale aren't a one-shot operation. They're a pipeline. Every script must be idempotent, every batch must be resumable, and every number must be verifiable. Plan for failure at every step, and the migration becomes reliable.”

Case Study #3

Full Stack Developer

4+ months

Building a 4-Tier Stripe Billing System From Scratch

Chordenet — Voice Email SaaS for US Clientchorde.net

NestJS

PostgreSQL

Stripe

Redis

BullMQ

Chrome Extension

Outlook Add-in

Chordenet is a voice email SaaS platform built for Luminos LLC (Denver, CO). Users record and send voicemails directly from Gmail and Outlook. The client needed a complete subscription billing system that could handle free trials, team accounts, discount codes, and seamless upgrades — all powered by Stripe.

The Challenge

14 pricing tiers (Free, Lite, Pro, Business) with both monthly and annual billing cycles — each with different feature gates and usage limits
2Team billing with seat management: admins invite members, add/remove seats mid-cycle, and Stripe must prorate correctly
3Lifetime discount codes that persist across plan changes — not just one-time coupons
4Free trial flow: 14-day trial → automatic conversion to paid, with grace period handling and dunning emails
5Chrome Extension for Gmail + Outlook Add-in had to respect subscription tier limits in real-time

The Approach

Stripe Architecture Design

Designed the billing around Stripe Subscriptions + Products + Prices. Each tier mapped to a Stripe Product with monthly/annual Price variants. Used Stripe metadata to store custom feature flags per tier.

Webhook-Driven State Machine

All billing state changes flow through Stripe webhooks — no polling. Subscription created, updated, canceled, payment failed, invoice paid — each event triggers a NestJS handler that updates the database atomically. Idempotency keys prevent double-processing.

Proration Engine

When a user upgrades mid-cycle (e.g., Lite monthly → Pro annual), Stripe calculates the proration. Built a preview endpoint that shows the exact charge before confirming. Downgrades take effect at period end.

Team Seat Management

Business tier supports team billing. Admins add seats (each seat = a Stripe subscription item quantity). Built invite flow, seat assignment, and removal — with immediate proration on seat changes.

Discount Code System

Created a system for lifetime discount codes using Stripe Coupons with `forever` duration. Codes are validated at checkout, applied to the subscription, and persist through plan changes and renewals.

The Results

4-Tier

Billing system

Billing cycles

100%

Webhook-driven

Browser extensions

Chrome Extension intercepts Gmail compose and adds voice recording UI
Outlook Add-in mirrors the same functionality for enterprise users
Master-sub account architecture for team management
Real-time tier validation — extensions check subscription status before every recording

Key Takeaway

“Never build billing logic outside of Stripe. Let Stripe be the source of truth for subscription state, and drive your app state from webhooks. The moment you start storing billing state independently, you create drift. Stripe webhooks + idempotent handlers = reliable billing.”

Case Study #4

Code Reviewer & Auditor

3 weeks

I Audited 4 Codebases and Found 50+ Security Vulnerabilities

Kitchen Konnect — Full-Stack Security & Performance Auditthekitchenkonnect.com

Node.js 22

Express 5

PostgreSQL

Next.js 14/15

React 18/19

Redis

Stripe

Docker

Kitchen Konnect is a food marketplace connecting home chefs with customers — live platform with real orders and payments. The client hired me to audit the entire stack before scaling. I reviewed 4 codebases: Node.js/Express backend, admin panel (Next.js), chef portal (Next.js), and customer website (Next.js).

What I Found

1Hardcoded Firebase credentials and AES encryption keys exposed in client-side JavaScript bundles — anyone could extract them from the browser
2Stripe webhook signatures were not being verified — an attacker could forge payment events and mark orders as paid without actually paying
3XSS vulnerabilities via dangerouslySetInnerHTML rendering user-generated content without sanitization
4Wildcard CORS on Socket.IO endpoints — any origin could connect to the real-time event stream
5Sharp image processing running synchronously on the main thread — blocking the event loop for 2-5 seconds per image upload
6Emails sent synchronously in API handlers — adding 1-3 seconds to every request that triggered a notification
7400+ console.log statements leaking sensitive data (user tokens, payment info) in production
8~3.5MB of unnecessary first-load JavaScript — libraries like Zego WebRTC and jsPDF loaded on every page regardless of usage

The Audit Process

Security-First Pass

Started with the highest-risk areas: authentication, payment processing, and data exposure. Found unverified Stripe webhooks, hardcoded secrets in client bundles, missing cookie security flags (HttpOnly, Secure, SameSite), and CORS misconfigurations.

Performance Profiling

Analyzed the Node.js event loop for blocking operations. Found Sharp image processing and synchronous email sending as the two biggest bottlenecks. Measured bundle sizes and found 3.5MB+ of code loaded unnecessarily on first page load.

Code Quality Assessment

Reviewed TypeScript usage — found 75+ `any` types bypassing type safety. Catalogued 400+ console.log statements that leaked sensitive data. Assessed error handling patterns and found bare catch blocks swallowing errors silently.

12-Category Scoring System

Built a consistent scoring framework across all 4 codebases: Security, Performance, Error Handling, TypeScript Quality, Code Organization, Testing, API Design, Database, Real-time, Authentication, DevOps, and Documentation. Each scored 1-10 with specific findings.

Phased Fix Roadmaps

Delivered priority-ranked roadmaps for each codebase — 4 phases, 27-30 action items each. Phase 1: Critical security fixes (do immediately). Phase 2: Performance wins. Phase 3: Code quality. Phase 4: Architecture improvements.

The Results

50+

Vulnerabilities found

Codebases audited

Scoring categories

120+

Action items delivered

Backend scored 5.5/10 — with Phase 1-2 fixes, a clear path to 8+/10
Admin panel: 5.0/10, Chef website: 5.0/10, Customer website: 4.5/10
Client prioritized Phase 1 security fixes and deployed within 2 weeks
Recommended moving Sharp to BullMQ workers and emails to a queue — estimated 3-5x API response improvement

Key Takeaway

“Most production codebases have security debt they don't know about. The scariest finding wasn't a single vulnerability — it was that the team had no process for catching them. A code audit isn't just about finding bugs — it's about building the awareness and processes to prevent them.”

Have a Similar Challenge?

Whether it's a complex migration, a billing system, or a security audit — I've done it in production. Let's talk about your project.

Discuss Your Project WhatsApp Back to Portfolio