Skip to main content
PandaCodeGen.

Work / MyCustomPatches / Independent client

MyCustomPatches

A decade-old WordPress store, off it in about 22 days, with zero downtime recorded at cutover.

MyCustomPatches ran on WordPress for years before moving to a custom Next.js build -- URL mapping and redirects were planned before cutover. The project record reports no ranking losses in the 30-day post-launch monitoring window.

The MyCustomPatches storefront home page after migration, showing the patch category navigation, the hero product imagery and the quote request entry point.
The storefront homepage after migration / Independent client
Migration completed in
about 22 days
Distinct templates rebuilt
13
Downtime at cutover
zero

One storefront, one template, one process.

A store built on one template,
backed by a real process.

The storefront customers browse, the product template that runs every category page, and the order process behind each purchase.

01 / Storefront

Eight categories, one entry point.

The public storefront: patch types organized as category cards, each leading to its own product page.

Chenille, PVC, woven, leather, shoe charms and embroidery are among the categories on the homepage, each with a short description and a direct link into that category's product page.

The homepage also carries an instant-quote entry point and a live chat widget, visible in the corner of this screenshot.

  1. 01

    Category grid

    Each category card links straight into that product's own page -- the same shared template every category runs on.

    Open full-size screenshot (new tab):
    The MyCustomPatches homepage showing category cards for Custom Chenille, PVC, Woven, Leather, Shoes Charm and Embroidery Patches.

02 / Product template

One template, every category.

Every product category page runs on the same shared template -- this one's Custom Chenille Patches, but the layout, fields and CTA are identical across all eight.

A photo gallery, a feature checklist, and the specifics that actually change a customer's decision: turnaround time (12 to 14 days standard, 4 to 7 days rush), minimum order quantity (as low as 50 units), and what's included (professional digitization, free revisions).

This is the same ProductPageTemplate component referenced in the migration record -- one template change applies to all eight category pages at once.

  1. 01

    Custom Chenille Patches

    12–14 day standard turnaround, 4–7 day rush, MOQ as low as 50 units -- the specifics a buyer actually needs, not filler copy.

    Open full-size screenshot (new tab):
    The Custom Chenille Patches product page, showing a photo gallery, a feature checklist and turnaround/MOQ details.

03 / Order process

Design to finished patches, four steps.

The page that explains how an order actually moves: submit a design, approve a mockup, wait for production, receive finished patches.

Submit Your Design (professional digitization included) → Approve Your Mockup (free revisions until perfect) → Production Begins (US quality standards) → Receive Ready Patches (12 to 14 days standard turnaround).

Each of the four steps has its own “Get Quote Now” button, rather than routing every visitor to one generic contact form.

  1. 01

    Design to production

    Four steps, each with its own detail and its own path to a quote -- not one generic “how it works” paragraph.

    Open full-size screenshot (new tab):
    The MyCustomPatches 'Your production partner from design to finished patches' page, showing four steps: Submit Your Design, Approve Your Mockup, Production Begins, Receive Ready Patches.

Design submitted, mockup approved, patches produced -- the same four-step process and the same product template across all eight categories.

04

Also in scope.

Search rankings lost, per Google Search Console: none recorded in the 30 days after launch. Performance figures were withdrawn pending reconciliation of the original test records. The old hosting cost figure was retired because no invoice or reliable recollection exists to support it.

Off a decade of WordPress, in about 22 days
Moved the WordPress store to Next.js in roughly three weeks. The team inventoried search metadata and mapped redirects where URL paths changed.
Forms with no server to maintain
Quote and contact forms run on React Hook Form with Zod validation, delivered by Web3Forms -- no custom form backend to run. Design-file uploads go straight to Cloudinary.
A single DNS cutover, not a slow migration
The new build ran in parallel on staging while the WordPress site stayed live. After QA, a single DNS cutover with a pre-lowered TTL made the switch, and the project record shows zero downtime at cutover.
FAQ

Questions about this project.

How did you handle URLs and search visibility during the WordPress move?
We inventoried the existing paths, mapped them to the rebuilt pages and added redirects where paths changed. The project record reports no ranking losses in the 30 days of post-launch Search Console monitoring. That observation has a defined window; it is not a guarantee about future rankings. An earlier URL-count claim has been withdrawn after an owner correction.
What made the rebuilt site faster than the WordPress original?
The performance figures for this project are withdrawn pending reconciliation, so we do not claim a measured speed improvement. The rebuild removed WordPress plugin dependencies and uses Next.js image handling and page rendering, but those implementation choices alone do not establish a before-and-after result.
How does the hosting model differ from managed WordPress?
The specific hosting figures for this project are retired: no invoices were kept and the client does not recall the amount. The original managed WordPress stack was replaced by a Next.js deployment on Vercel with Cloudflare. We do not have a verified traffic split or hosting-cost comparison for this project.
Was there any downtime during the migration?
The project record reports zero downtime at cutover. The new site was prepared on staging while the WordPress site stayed live, then switched over after QA. We have no separate visitor-level timing measurement to quote.
What happens to the quote forms and file uploads after migration?
Quote forms use React Hook Form and Zod validation with Web3Forms for delivery; customer design uploads use Cloudinary. We have not published a measured before-and-after form reliability result.

Stuck on an old platform you're afraid to touch?

Tell us what you're running and what you're afraid of losing, and we'll work out what a careful migration would take.