Tony James Designs – Modernising an Established International Store
Tony James Designs had run its international motorcycle paint-protection store on WooCommerce for years, and it worked. Asked to update the website, I recommended something different: keep the business exactly as it operates, and replace the platform underneath it. The old store was mapped in detail first, including a configurator driven by 610 conditional elements, then rebuilt as a bespoke Next.js and Payload application. Products, customers and order history came across intact, followed by practical improvements: better search, launch-interest capture, built-in shipment tracking and a partner directory.
Jump to a section
Built with
- Next.js
- React
- TypeScript
- Payload CMS
- MongoDB
- Tailwind CSS
- Node.js
- Stripe
- PayPal
- Nodemailer
- PDFKit
- Sharp
- Claude API
At a glance
Client
Tony James Designs, a specialist maker of motorcycle paint-protection kits selling to riders worldwide
The starting point
an established WooCommerce store that needed updating
The recommendation
keep the business exactly as it works, and replace the technology underneath it
What I built
a bespoke Next.js and Payload commerce platform, migrated from the original store without losing its products, customers or order history
The starting point
Tony James Designs makes paint-protection kits shaped to fit specific motorcycles, from tank and pannier protection to full kits, and ships them to riders around the world. Tony had run the business on a WordPress and WooCommerce store for years, and it worked. Riders found their bike, chose their kit, paid, and received a tracking number.
Tony came to me because the website needed updating. The obvious job was a refresh: a new theme, some new pages, a few more plugins.
Before recommending that, I looked at what the store actually consisted of.
287 products and 541 product variations.
More than 200 motorcycle models and model years across nine manufacturers.
Around 2,100 orders, of which 1,875 carried shipment-tracking records.
Around 280 customer accounts.
13 international shipping zones.
Around 30 plugins between them providing the store's behaviour.
The recommendation
WordPress isn't the problem; it runs a large share of the web very well. The issue was what this particular store had become over the years. Much of what the business depended on, from the product configurator to shipping rules, tracking, reports and forms, lived in separate plugins from different vendors. Each had its own settings and update cycle, and none was designed around Tony's business.
Refurbishing that would have meant investing further in the same arrangement: a new look over the same stack of plugins, with each future feature meaning another plugin to find, adapt or write.
So I recommended the less obvious option: preserve the business exactly as it works, and replace the platform underneath it with a modern application Tony owns, where new features become part of the product rather than another add-on.
Modernisation doesn't always mean reinventing a business. Sometimes the right decision is to keep a successful operation intact and change the technology it runs on.
Understanding what already worked
Nothing was rebuilt until the existing store had been understood in detail. Working from a full backup of the site and its production database, every relevant plugin's configuration was decoded from the data it had stored, rather than guessed from the plugin's name. The result was a written specification of the store as it actually behaved:
the catalogue, its brand and model structure, every product variation and every image
the configuration rules behind each product's options
shipping zones, rates and the conditional rules on top of them
payment gateways, coupons and tax settings
customers, orders, refunds and shipment-tracking history
pages, blog posts, galleries, forms and SEO titles and descriptions
Decoding the data, rather than trusting appearances, also showed what didn't need rebuilding:
No tax was configured anywhere, so no tax engine was needed.
Product options never changed the price, which is set by the chosen variation alone.
A personalisation and upload plugin was installed but had never been used.
Only two payment gateways were live, Stripe and PayPal, and the conditional shipping amounted to three rules.
Every one of the roughly 30 plugins was given an explicit decision: rebuild natively, fold into the new data model, replace with the platform's own capabilities, or retire. Behaviour that mattered to the business was preserved deliberately. Behaviour that only existed because of the plugin architecture didn't need a plugin-shaped replacement.
Rebuilding the commerce engine
The product configurator
For the business: a rider needs the right kit for their exact bike, and the shop should guide them there without exposing the complexity underneath.
Under the hood: this was the most demanding part of the rebuild. On the old store, an extra-product-options plugin drove the choices on 242 of the 287 products. 239 of those used conditional logic, adding up to 610 conditional elements: pick the model, and the right list of colours or kit types appears; change the model, and the options change with it. 218 required fields stopped a rider adding a kit to the basket until every choice that mattered had been made.
Each product's stored configuration was decoded from the old plugin's format and migrated, rules and all. Shared option sets that apply to several products are kept as one record, so an edit reaches every product that uses it. Audit scripts checked the migrated rules against the original data, so gaps couldn't slip through unnoticed. On the product page, the variation selector, dependent dropdowns and required choices behave as they did, and the basket button stays disabled until the kit is fully specified.
Catalogue and media
For the business: the whole range came across without re-entering a single product by hand.
Under the hood: migration scripts read the WordPress database directly, bringing across the brand and model categories, tags, products and variations, descriptions, images and shipping classes. The scripts were written to be re-run safely, updating records rather than duplicating them. Product addresses kept their original URLs.
Customers and order history
For the business: returning riders still have their account and every past order.
Under the hood: customers and around 2,100 orders were migrated with their line items, coupons, totals and shipment tracking. WordPress passwords can't be carried into a new system, so migrated customers are asked to set a new password the first time they sign in, and then find their full order history waiting.
Shipping and payments
For the business: international pricing and checkout carried on working the way customers knew.
Under the hood: shipping zones by country, continent and postcode, flat rates with per-class supplements, and the three conditional rules are all rebuilt natively and editable by staff. Checkout supports card payments through Stripe and PayPal, discount codes, and saved payment methods managed through Stripe's secure customer portal. Customers can download a PDF invoice for any paid order.
Beyond like-for-like
With the important behaviour preserved, the new architecture made it straightforward to add things that would previously have meant another plugin.
Search that finds your bike
For the business: Tony singled out search as noticeably better than the old site's. For a catalogue organised by bike, finding your model is the first and most important step.
Under the hood: search runs as you type across the whole catalogue, matching product titles and brands, and offers matching motorcycle models in a dropdown. Matching ignores spacing, case and punctuation, so "panigale v4" finds "Panigale V4". Brand pages add one-tap shortcuts for popular models, results are ordered by model year, and the catalogue is rendered on the server so search engines see it too.
Interest in kits that aren't ready yet
For the business: when a new motorcycle is released, riders want protection for it before the kit exists. That demand can now be captured instead of lost, and turned into sales on launch day.
Under the hood: products still in development show as "In Design, Coming Soon" and invite riders to leave their details. The moment Tony switches the product to available, everyone waiting is emailed automatically and marked as notified. On the old site this kind of feature would have meant another plugin. Here it is part of the product and its data model.
Shipment tracking for customers and for Tony
For the business: for a business shipping worldwide, "where's my order?" is a question worth answering before it's asked. Tracking was already central, with 1,875 historical orders carrying it. Now it's built in for both sides.
Under the hood:
When Tony dispatches an order, he picks the carrier from a managed list and enters the tracking number. The tracking link is filled in automatically from that carrier's template.
The customer is emailed once per shipment with a link to follow the delivery, and can see tracking on their order page.
Orders paid by PayPal have their tracking sent to PayPal automatically, so the buyer sees it there too and the shipment counts towards PayPal's Seller Protection.
In Tony's order list, every tracking number is a link straight to the carrier's live tracking page.
A partner directory
For the business: a kit is only as good as its fitting. Riders can find approved fitters and stockists near them, which supports the people who install Tony's products.
Under the hood: the public partners page shows approved fitters and stockists on a map, each pin opening a details card with contact information and a link to their website. Tony adds partners in the admin. Each one is placed on the map automatically from their postcode, and an exact position can be set by hand when needed.
Running the shop
For the business: the day-to-day tools sit in one place Tony controls.
Under the hood: a monthly sales report replaces the old reporting plugin, with month and year filters, fee totals and a print view. Customer emails use editable templates, and every send is logged. When Tony is signed in, "edit this product" and "edit this category" shortcuts appear on the shop pages themselves. Optional AI assistance, built on Anthropic's Claude, drafts product search descriptions and blog posts for him to review.
An international operation
Tony sells to riders across the UK, Europe, Australia, North America and the Far East, and the platform carries over the operation that supports that:
13 shipping zones, including the UK, a 31-country European zone, the US, Canada, Australia, New Zealand, South Africa, Singapore, Malaysia, the Philippines, Taiwan and the Channel Islands, plus a rest-of-world fallback
a shipping quote calculated in the basket from the destination and what's being sent
international card and PayPal payments
tracking emailed to the customer and shared with PayPal
customer accounts with order history and invoices
The outcome
Tony now runs the same business on a platform built around it:
The established operation preserved: catalogue, configurator rules, shipping, payments, customers and order history.
One application Tony controls, in place of around 30 independently maintained plugins.
A configurator faithfully migrated, with 610 conditional elements, and audited against the original data.
Better search across the bike catalogue.
Launch-interest capture with automatic notification.
Built-in shipment tracking for customers, for Tony and for PayPal.
A partner directory of approved fitters and stockists.
A cleaner foundation for the next feature, without another plugin.
For established businesses
Plenty of businesses run on a website that has quietly accumulated years of logic: custom options, shipping quirks, reports and forms, each added by a different plugin at a different time. Replacing it carelessly loses things that matter. Refreshing it forever means paying to maintain a structure nobody designed.
The same approach applies to any established online business: WooCommerce and WordPress shops, older bespoke systems, and platforms stitched together from add-ons. Understand what the business actually depends on, keep that intact, and rebuild only what genuinely needs to change.
Technical stack
For readers interested in the technology:
Next.js 16 (App Router) and React 19 in TypeScript, Payload CMS 3 on MongoDB, Tailwind CSS, Stripe (Payment Element, webhooks and customer portal), PayPal Orders and tracking APIs, Nodemailer, PDFKit for invoices, Sharp for images, Anthropic's Claude API, and migration tooling that reads the original WordPress database directly.
Is your website holding years of business logic?
Your existing site may contain years of valuable business logic. Modernising it starts with understanding what needs to be preserved, and what no longer needs to be there.
If your platform has grown past the point where another refresh makes sense, let's look at it together before deciding what to rebuild.