Case studies

Problems solved in production.

Five projects described the way they actually happened — what was broken, what I did about it, and what changed as a result.

Beauty Frizz Bethesda WooCommerce storefront

WordPressWooCommerceAffirm live

A live WooCommerce store that lost its database mid-trading.

The problem

The client's WordPress store went down with its database wiped — no products, no pages, no orders. A working storefront had become a blank error page while the business was actively taking bookings.

What I did

Restored the WordPress installation and got the site serving again, then rebuilt the product catalogue and page structure. Once the store was stable I installed and configured Affirm as a live production payment gateway, so customers could finance treatments at checkout, and verified the gateway end to end rather than trusting the plugin's own status indicator.

Result: the store was back online and taking real payments within a day — with financing available that it never had before.

Queen Bee Spa San Diego Next.js storefront

Next.jsStripe liveMigration

Nine storefronts that could be browsed — but not bought from.

The problem

A group of client stores had been built and handed over with placeholder checkouts — buttons that looked real, collected customer details, and charged nobody. Several were also sitting on hosting the client didn't control, with no way to inspect a failed order.

What I did

Migrated each store onto managed Linux hosting the client owns, with automatic HTTPS and supervised services so a crashed process restarts itself. Then replaced the fake checkout with real Stripe integration — embedded checkout, a working cart, webhook handling for order confirmation — and tested each store against live account state instead of assuming the API keys were good. On more than one, that check was what revealed the account wasn't actually enabled for charges yet.

Result: nine storefronts running genuine checkout on infrastructure the client controls, with payment failures visible and debuggable.

Meta CAPICRM bookingLanding pages

163 landing pages, each with its own pixel, calendar, and timezone.

The problem

An agency needed a landing page per treatment per location, each with live appointment booking, its own advertising pixel, and its own local timezone. Hand-building them would have been slow and inconsistent — and inconsistent tracking makes the ad reporting worthless, which defeats the point of the pages.

What I did

Built a repeatable mobile-first page template with a booking flow that reads genuine availability and posts appointments straight into the client's CRM. Each page carries a browser pixel plus a server-side Conversions API integration, sharing event IDs so a single booking is deduplicated into one conversion instead of two — the difference between a campaign that looks twice as good as it is and one you can actually budget against.

Result: 163 pages in production with conversion reporting the agency can trust, and a new page live in under an hour.

Palm Desert Bee and Co WordPress WooCommerce store

WordPressElementorWooCommerce

A WooCommerce catalogue built out, product by product.

The problem

A retail client had a WordPress site running Elementor on an Astra theme, but an incomplete store — missing informational pages, and a product catalogue that existed on paper rather than on the site.

What I did

Built the missing pages in Elementor so they matched the existing design system rather than looking bolted on, then loaded a 30-product catalogue into WooCommerce with correct categories, pricing, descriptions, and imagery — driving it through the WordPress REST API for speed and consistency instead of typing each product into the admin by hand.

Result: a complete, fully editable store the owner can maintain themselves without calling a developer.

Client storefront migrated onto managed hosting

AttributionMeta APIDashboards

The dashboard that found conversions were being counted twice.

The problem

Ad spend decisions were being made on advertising-platform numbers that nobody had ever checked against reality. If the platform reported forty bookings, there was no way to confirm forty bookings actually existed.

What I did

Built an internal reconciliation dashboard that matches ad-platform reported conversions against real appointments in the CRM, per client, with each client's own timezone handled correctly — a detail that silently misaligns dates by a day when it's ignored. Put it behind authentication and had it refresh continuously so it could be trusted as a daily working tool.

Result: exposed 2–3× over-reporting on several accounts, plus a disconnected CRM account that was still spending money — moving budget decisions onto numbers that hold up.

Available for work

Have something similar?

Send me the URL and what it needs to do. I'll tell you honestly what I think it needs — including when that's less work than you expected.

ivanralphquezon@gmail.com Browse live sites