Dhaka, Bangladesh

Case Studies

WowShipping Frontend Engineering - 4 Case Studies

WowShipping Frontend Engineering - 4 Case Studies

4 case studies from the WowShipping WooCommerce shipping plugin's frontend: a Gutenberg component migration that didn't survive a branch merge, a hand-built drag-and-drop interaction, a naming-convention overhaul, and a domain-vocabulary rename.
Shipping Rules to Shipping Methods Rebrand

Shipping Rules to Shipping Methods Rebrand

How I renamed WowShipping's primary UI concept from "shipping rules" to "shipping methods" across 45 files - and what deliberately stayed unrenamed underneath.
Renaming a Component Library to Kebab-Case

Renaming a Component Library to Kebab-Case

Five commits, one calendar week - converting an entire WooCommerce plugin's component library, page folders, and context files from PascalCase to kebab-case, then regrouping local components into their own subfolder.
Native Drag-and-Drop Without a Library

Native Drag-and-Drop Without a Library

Reordering shipping methods needed drag-and-drop. I built it on the raw HTML5 Drag and Drop API - including the ref-counter fix for the classic dragenter/dragleave flicker bug - with no new dependency.
The Select Component Trade-off: Migrating to Gutenberg's SelectControl

The Select Component Trade-off: Migrating to Gutenberg's SelectControl

I migrated a shared Select wrapper to Gutenberg's native SelectControl behind a preserved prop API. Tracing the commit history later, I found the migration didn't survive the next branch merge - and nothing broke anyway.
AI Recommendation Builder That Had to Keep Up With Its Own Rule Book - 3 Case Studies

AI Recommendation Builder That Had to Keep Up With Its Own Rule Book - 3 Case Studies

The admin builder for a WooCommerce product-recommendations plugin - a visual placement tool where the state model, the rule vocabulary, and two near-identical components all had to grow without breaking each other. Three linked case studies.
When a Screen's Data Outgrows Its Own Update Code

When a Screen's Data Outgrows Its Own Update Code

A WooCommerce recommendation builder needed several independent lists per placement, not one - why I kept the nested state shape and adopted Immer instead of flattening it.
Turning a Growing Rule Vocabulary Into Data Instead of Code

Turning a Growing Rule Vocabulary Into Data Instead of Code

A recommendation builder filter vocabulary kept growing - category, price, browsing behavior, purchase history, each with its own valid operators. Why I moved that vocabulary into data instead of component logic.
Two Rows That Look the Same and Aren't

Two Rows That Look the Same and Aren't

A recommendation builder needed a filter-rule row and a sort-rule row that looked almost identical - why we built them as siblings instead of one shared abstraction, and how I kept them from drifting apart.
A Shared Component Architecture in a Monorepo - 4 Case Studies

A Shared Component Architecture in a Monorepo - 4 Case Studies

A solo, year-long build of a 44-component Vue library shared between two independently built apps inside a WordPress booking plugin - four linked case studies covering API boundaries, state, resilient input handling, and codebase structure.
Structuring a Large Frontend Codebase for Maintainability at Scale

Structuring a Large Frontend Codebase for Maintainability at Scale

Two independently-built Vue apps and a webpack-built Gutenberg block shared one component library through a consistent alias system and a per-app Tailwind purge - except in the one place plain CSS won.
Engineering Resilient Input Components for Real-World Data

Engineering Resilient Input Components for Real-World Data

Building a price input for PreBook that reformats live with locale-correct separators while keeping the text cursor exactly where the user left it.
Centralizing State Management Across a Multi-App Architecture

Centralizing State Management Across a Multi-App Architecture

Migrating 21 Pinia stores across two independently-built Vue apps to the Composition API, and routing their data-shaping logic through one shared model layer instead of duplicating it in each store.
Designing Component APIs That Scale Across Two Applications

Designing Component APIs That Scale Across Two Applications

PreBook ships two independently-built Vue apps against one shared component library with no package boundary, so every reusable component forces the same question - what generalizes, and what stays local to the app that needs it.
Refactoring a 40k Users Frontend - 5 Case Studies

Refactoring a 40k Users Frontend - 5 Case Studies

A self-proposed, solo-executed refactor of a WordPress Gutenberg plugin used by 40,000+ users - five linked case studies covering the technical execution, the decision, the trade-offs, and the risk.
What a Self-Proposed Engineering Initiative Looks Like

What a Self-Proposed Engineering Initiative Looks Like

I noticed a legacy system blocking my feature work and fixed it without being asked - a case study in product-minded engineering judgment.
JavaScript Linting & Formatting Setup for a WordPress Gutenberg Plugin

JavaScript Linting & Formatting Setup for a WordPress Gutenberg Plugin

Adding ESLint and a formatter to a Gutenberg block plugin codebase - the groundwork that made the CSS refactor safer, and the paired initiative behind it.
CSS Architecture Refactoring in a WordPress Gutenberg Plugin

CSS Architecture Refactoring in a WordPress Gutenberg Plugin

How I split a 6,262-line monolithic stylesheet into 19 component files - solo, self-proposed, in a WordPress plugin with 40,000+ users.
Bundle Size After a CSS Split: Measuring What Actually Changed

Bundle Size After a CSS Split: Measuring What Actually Changed

I expected splitting one stylesheet into 19 files to cost bundle size. The first measurement said it grew - until I isolated unrelated image assets and re-measured: a 20-30% reduction.
Refactoring Legacy Code With No Test Suite

Refactoring Legacy Code With No Test Suite

How I refactored 13+ dependent files with no automated tests - what I verified manually, what the risks were, and what I would do differently next time.