The constraint: nothing underneath moves

By the time Datum started, the store was carrying a lot that customers never see: the cart's live shipping estimate on its Railway proxy, the AI chat agent's mount point, a pre-order app, Rapid Search on the results page, analytics, and hundreds of links pointing into the mega menu and collection tree. A redesign that broke any of those would have cost more than it delivered.

So the brief I set was narrow on one side and wide on the other: change every surface, keep every connection. The metafield hierarchy, the collection tree and every URL stayed exactly where they were; the design on top of them was redone from the homepage down.

Filters first

Before touching the look of anything, I rebuilt how buyers narrow a catalogue this size. The new collection filtering runs on Shopify Search & Discovery — brand, series, dimensions, mounting type, price, accessory type and depth — and now sits on 120+ collection pages, for example Electrical Automation Cables.

The search-results filter bar was redesigned alongside it: tighter spacing and alignment, visible active-filter states, a working clear-all, and the same layout on desktop and mobile. Product grids got two modes — horizontal rows for scanning SKUs, tiles for browsing — and I explored several layout concepts in Claude Design before committing any of them to Liquid. A broken Rapid Search JavaScript snippet on the results page was fixed in the same stretch.

Every surface, redesigned

• Homepage. A new hero with key business stats, a brand-logo band, parent categories with their own navigation, and redesigned Trending Products, Case Studies and Customer Reviews sections.
• Mega menu. Redesigned for spacing, hierarchy and click behaviour, with every existing link and the navigation structure left intact — then its logic and hierarchy fixed again after launch.
• Navbar and footer. The Datum visual style, same links, same integrations.
• Collection subcategories. Clearer visual hierarchy, product counts, alignment and responsive behaviour.
• Listing pages and PDP. Product layouts, specifications, breadcrumbs, descriptions and related products refined; image overflow, Pre-Order button placement, and Add to Cart and Enquiry glitches caused by app injection all fixed.

How the month went

• Days 1–3New filter system, search-results filter bar and product grid concepts; UI/UX fixes across collection, search, listing and product pages; mobile and desktop validation.
• Days 4–5SMC Brand page built and SMC Distributor refined; Siemens page redesigned and deployed; Globo Pre-Order injection resolved with their support team.
• Days 6–7Mega menu, navbar, footer, subcategories, listing pages and PDP redesigned in Datum; homepage rebuilt section by section and put up for review.
• Day 8Cross-device testing and bug fixing; Saudi redesign begins.
• Days 9–17Saudi theme in two versions; cart shipping calculator fixed; pickup moved to Ajman; bot traffic traced and shut out; post-launch fixes to templates, mega menu logic and hierarchy.
• Day 18TIA AI Product Search and The Toolkit pages designed, written and launched.

Running it

The redesign went live, and then the unglamorous part started. Rapid Search began reporting that the plan's session limit had been exceeded. The traffic analysis showed why: a large volume of bot traffic from the USA, each bot visit counted as a search session. I took it to Rapid Search's support and technical team, had bot traffic excluded and the plan reset to count real visitors only, and then closed the door on the site's side with robots.txt rules, rate limits and session timeouts aimed at bot and data-centre traffic. Filters and search results now show accurate counts again.

• Cart shipping calculator. Broke, was traced and fixed — including updates to the Railway proxy integration and a cleaner cart UI.
• Third-party app conflicts. Globo Pre-Order's script injection was misplacing and breaking the Pre-Order button; resolved together with their support team.
• Pickup location. Switched from Al Qusais to Ajman, with pickup availability on the product page configured to match.
• Template and rendering bugs. Product-page template issues and product rendering bugs cleared as they surfaced after launch.

Shipped alongside

TIA — AI Product Search gives the chat agent a page of its own: a buyer describes the part in their own words, or types a part number or brand, and the AI searches the catalogue for a match. Example prompts — proximity sensors, safety switches, Bonfiglioli gearboxes — show what it's good at; parts lists save with a login, and the linked chat keeps new and previous conversations.

The Toolkit is a free Excel workbook for maintenance and spares planning — downtime cost calculator, machine risk map, critical spare score, spares register, planned maintenance and spares planner, KPI scorecard and emergency log. No registration, email or login; it opens in Excel and Google Sheets. It gives an engineer a reason to come to the site that isn't a purchase yet.

Why rebuild instead of iterate

The store had been through twenty-two theme builds — mine, all of them — and each one made the previous layout a little more capable and a little more crowded. The catalogue had grown past 200,000 parts and 450 product lines, and the interface was still shaped around a much smaller store: a menu that didn't scale to three levels, collection pages that treated subcategories as an afterthought, a product page that buried the specification a procurement engineer came for.

So the twenty-third build was not an iteration. New grid, new type scale, new component set, a different information hierarchy, and a visual language of its own — monospaced technical labels against a heavy display face, orange as the only accent, hard edges instead of soft cards. Industrial, not e-commerce-generic.

The theme it replaced

Here is what the store looked like before. It isn't a bad storefront — it's a general-purpose e-commerce layout doing its best with an industrial catalogue. Hero panel with a slogan, a tabbed category picker, a "Trendy Products" carousel, and collection pages that lead with a marketing paragraph before anything you can click.

Two things in particular pushed the rebuild. The hero advertised 10M+ products and 20+ brands — numbers nobody could reconcile with the catalogue, and a buyer who searches a part number and finds nothing trusts the site less for having claimed them. And the browsing model assumed discovery: tiles, trending, best sellers — with nothing on the page that accepted a part number first.

What did carry across untouched was the part that lives in data rather than in templates: the metafield hierarchy, the subcategory relationships and the filter definitions. The redesign is a new front end on the same spine — which is exactly why it could ship in days rather than months.

And after

Navigation that survives 451 product lines

The mega menu resolves three levels — category, subcategory, brand — with live part counts at every level, all of it read from the same custom.parent_collection metafield chain that drives breadcrumbs and filters. Nothing in the menu is hardcoded, so a new subcategory appears the moment its collection exists.

Collection pages that explain themselves

Every collection leads with its subcategories as image tiles with part counts, then a status bar — total parts, in stock, pre-order, no stock — then the products, in a grid or a dense list the buyer can toggle. The list view is the one procurement people actually use: SKU, brand, type and price on one line, add to cart or enquire without leaving the page.

Product page and cart

The product page opens on the breadcrumb path the metafield chain generated, the SKU and brand as a linked line, and the specification panel enlarged. Pre-order items carry their lead time next to the button rather than in fine print, and pickup availability resolved against the store's pickup location — Al Qusais at the time, since moved to Ajman. Related products come from the deepest collection the part belongs to, not from a generic "you may also like".

Search built for part numbers

Search states what it did — how many results, across how many indexed part numbers — and offers brand narrowing immediately, which matters when a query like ifm hits four vendor spellings at once. The filter rail is metafield-driven: brand, series, cable length, mounting type, whatever that category actually has. Both result views are available here too.

Getting it live — and what came next

The theme was shown internally, approved, and pushed to production days later — the company wanted it live as soon as they saw it. The previous build stayed on the store, unpublished, which made the switch reversible on the day and makes the comparison easy to run now: open the pre-Vision theme in preview and put it next to the screenshots above.

Everything downstream came with it: the cart's live shipping estimate, the AI chat agent's mount point, PostHog, the pre-order system, and the breadcrumb and filter architecture that the previous twenty-two builds had grown. That same spine is what let the next build, Datum, redesign every page again in September 2026 without moving a single link.

The problem

OTO aggregates delivery providers across the Gulf. Its delivery-fee endpoint authenticates with a long-lived refresh token exchanged for a short-lived access token. A Shopify theme is public JavaScript — anything the cart page can read, a customer can read — so calling OTO from the storefront would have published the account's credentials.

The alternative was what the store was already doing: leave shipping until checkout, and lose the carts that were price-sensitive about it.

What I built

A small Express service on Railway between the storefront and OTO, exposing one public endpoint: POST /api/shipping-estimate, taking a destination city, a chargeable weight and an optional order total. It returns a flat list of carrier options with price, ETA and logo.

Everything sensitive stays server-side. The refresh token lives only in Railway's environment — never in the repo, a commit, or a log line. The service exchanges it for a one-hour access token, caches it in memory, refreshes proactively around the 55-minute mark, and retries once if OTO returns a 401 or 403 mid-request.

The parts that matter in production

• CORS allow-list so only the store's own domains can call the endpoint.
• Two layers of rate limiting — 30 estimate requests a minute, plus a 120/min baseline across all routes, health check exempt.
• Short response cache, because ten shoppers in Riyadh with a two-kilo cart should not be ten calls to OTO.
• Timeouts and bounded retries upstream, so a slow carrier API degrades into a missing estimate rather than a hanging cart.
• Weight ceiling validated before the upstream call.
• Mock mode returning canned carrier data with no token, so the widget can be built locally without touching production credentials.
• Kept alive after launch. When the calculator broke in September 2026, I traced and fixed it — updating the Railway proxy integration and refining the cart UI in the same pass.

The cart side

The widget renders from the cart footer section. It reads /cart.js, converts line-item grams into a chargeable weight in kilograms, and posts that with the selected city. Carrier rows render with price, estimated window and — deliberately — the cash-on-delivery surcharge as a separate note rather than folded into the headline number.

Where it stops

The estimate is display-only and labelled that way — rates are quoted by delivery city, the postal code is ignored, and Shopify still calculates and charges its own rate at checkout. This shows an indicative cost early, at the moment it decides whether the cart survives.

Architecture

It's a Shopify Dev Dashboard app, not a legacy custom app — OAuth session tokens, a theme app extension and an app proxy, with no permanent admin token anywhere in the system. The storefront half is a Liquid block plus chat.js injected into the theme; it posts to /apps/shop-chat/chat, Shopify's edge forwards that through the app proxy to a Dockerised React Router backend on Railway.

The backend opens two of Shopify's own MCP servers per session over JSON-RPC: Storefront MCP for catalogue search and cart, and Customer MCP for order history and returns behind a customer PKCE OAuth flow. Tools are discovered with tools/list and handed to Claude as available tools; when Claude calls one, the backend dispatches to the right MCP server and streams the result back over SSE as a typed event — product_results, cart_updated, end_turn. Postgres via Prisma holds sessions, conversations, messages, visitors, leads and analytics.

Search on a catalogue this size

The first version asked the model to guess — which fails the moment a buyer types a partial SKU shared by four hundred other parts. I rebuilt search to query the Storefront API directly with a strategy: broad full-catalogue query first, an intelligent retry on a simplified query, then a multi-level fallback. SKU-shaped input is detected and ranked by exact match; a brand name in the query infers a vendor filter. The same pass deleted a redundant search layer and unnecessary API calls that were adding latency to every message.

The production-only failures

• A Storefront token 401 loop. Token logic had been written against a legacy OAuth flow. Rebuilt on the official Admin REST flow with proper refresh and validation, which also cleared the cart failures and domain leakage behind it.
• Shopify blocking the app as a security threat. Reconfiguring the app proxy and correcting the request path cleared every security error.
• Cart operations failing silently. Add to cart and checkout now run inside the chat, against the Storefront GraphQL API directly — cartCreate and cartLinesAdd — with validation on each call.
• Shop domain resolution. App-proxy requests are same-origin, so there is no Origin header to read, and the MCP endpoints only accept the *.myshopify.com domain — a custom domain fails outright. The backend resolves the shop from the proxy's own ?shop= parameter first, then falls back to the header and an environment variable.

Conversation and interface

Session handling covers new chat, end chat, history hydration without duplicate threads, and email capture so a conversation that doesn't convert still becomes a lead — leads are stored per shop and visitors carry a fingerprint and UTM trail. Product results render as a carousel with a modal detail view; the input auto-expands; a multi-phase indicator shows what the agent is doing rather than spinning at the user.

Later I upgraded the Claude model and rewrote the system prompts for cleaner tool queries and better instruction-following, which noticeably reduced empty and incorrect results on multilingual and ambiguous questions — a real requirement for a Gulf storefront.

A front door: the TIA page

A chat bubble in the corner only helps the people who notice it. In September 2026 I built TIA — AI Product Search, a full page that puts the agent's capability up front. A buyer describes what they need in plain words, or enters a part number or brand, and the AI searches the catalogue to match parts to the application. The Ask-TIA input comes with example prompts — proximity sensors, safety switches, Bonfiglioli gearboxes — parts lists save against a login, and the linked chat keeps new and previous conversations.

The agent is also still mounted on every page of the live store, bottom right. Open it and ask for a part number.

The structural decision

Two hundred thousand products can't be organised by hand, and a catalogue that grows every month can't be organised by template. So the category structure lives in data: every collection carries a custom.parent_collection metafield, and the theme walks that chain to render subcategory cards, breadcrumbs and filters.

That one decision is why 270 collection pages and 120 new subcategories could be added from a forty-thousand-product file without a new template, why breadcrumbs across the store auto-generate the deepest correct path with zero per-product setup, and why two complete theme redesigns — Vision, then Datum — could be dropped on top of it without re-tagging a single product.

Finding things

Metafield-based filters first ran across 200+ collection pages with Rapid Search. Getting there meant diagnosing filter-definition conflicts with both Shopify and Rapid Search support, and securing a custom plan sized for a 200k-product limit. The AODD pump range shows what the structure buys: sixty-plus collection pages across size, material and diaphragm variant, all with working filters, breadcrumbs and mega-menu entries.

In September 2026 collection filtering moved to a new system built on Shopify Search & Discovery — brand, series, dimensions, mounting type, price, accessory type and depth — now live across 120+ collection pages, with a redesigned search-results filter bar, clear active-filter states and row or tile product views. Rapid Search still powers the search results page.

When the traffic isn't real

Search plans are metered by session, and in September the Rapid Search plan hit its limit. Traffic analysis showed heavy bot traffic from the USA being counted as real sessions. I worked it through with Rapid Search's support and technical team — bots excluded, plan reset to count real visitors only — and added robots.txt rules, rate limits and session timeouts on the store to keep bot and data-centre traffic out. Filter and result counts are accurate again.

The unglamorous half

• Import. ~40,000 products loaded file by file to avoid duplicates. Broken imagery traced to CSV links pointing at unstable Google PageSpeed URLs — 4,974 corrected and re-imported via Matrixify.
• Pre-orders. Cart drawer replaced with a dedicated cart page: pre-order buttons with lead times, stock badges and counts, and a warning that fires only on mixed carts. When the Globo Pre-Order app's script injection later broke the button, fixed with their support team.
• Product pages. Larger specifications panel, SKU + brand line linking to the vendor collection, tariffs & fees tab, bigger imagery, direct route to a specialist, and pickup availability now pointed at the Ajman location.
• SEO. One H1 per template, ALT text across 270+ collection pages, content on ten IFM collection pages, related products from the deepest assigned collection.
• Measurement. PostHog across the site where previously there was nothing to look at — and traffic analysis that caught the bots.

What came out of it

A second storefront for Saudi Arabia launched from the same theme in May 2026 with regional details, a dual-office footer, redirects disabled so Saudi clicks stay on the Saudi site, and its own distributor landing page. In September it got a new theme of its own — redesigned landing page, header, logo, navigation, and category and product-range sections on Shopify CDN imagery — delivered as two versions for the company to choose between, with the remaining invalid links and UAE redirects removed for products not yet sold in KSA. A structure built to be reused turned out to be reusable.

The brief

Someone clicking a Siemens ad is usually holding an MLFB article number. Someone clicking an SMC or IFM ad is usually holding a model string, or a specification they need help turning into one. Neither wants a product grid with add-to-cart buttons, and neither is served by a price that may not survive contact with a distributor quote. So on these pages there are no prices and no cart. Every card ends in an enquiry: Email for quote, WhatsApp, or an Enquiry button.

Siemens: article number first

Eight numbered product families — SIMATIC controllers, SIRIUS switching, SITOP power, SENTRON protection, command and signalling, industrial communication, motors and drives — each expanded into its own block with series chips underneath (S7-1200 / S7-1500, ET 200SP, 5SL MCBs, PAC3120 / PAC3200). The chips exist because that's the vocabulary the buyer arrives with; the ad keyword and the on-page label match.

Every card leads with the article number in monospace, above the name, above a one-line spec. That ordering is deliberate: the number is what gets matched against, so it goes first.

In September 2026 the page was redesigned and redeployed: layout reworked, sections removed and added, real product images and Enquiry buttons integrated throughout, and mobile and desktop tuned again. The screenshots below are from the version before that pass.

Saying what isn't in stock

The strongest section on the Siemens page is the one that admits a limit. Also supplied to order lists the families that aren't held in web stock but get sourced regularly for project and panel-build work — SIMATIC HMI, SINAMICS drives, SITRANS instrumentation, SCALANCE networking, ET 200, SIRIUS safety — each with an Ask for a lead time button rather than a fake availability badge.

Above it sits the part-number check: send an article number and get back availability, current pricing, and the correct successor where the original has been discontinued. Discontinuation is a real problem in this catalogue, and offering to resolve it is a better reason to make contact than a discount would be.

SMC Distributor: the same pattern, a different vocabulary

SMC came first and set the template. The structure rhymes — a hero that names the enquiry route, a category strip, then one block per family with sub-type chips and cards ending in a quote action — but the content works at a different level. SMC parts are configured rather than looked up, so the cards describe types: ISO standard, compact, rodless, guided; one-touch, stainless, brass, push-in. The buyer picks the shape of the thing, then talks to a person about the exact model string.

The hero puts the sales address in a box as the primary action, with WhatsApp beside it, and labels it for what it's best at: part numbers, BOMs, drawings and bulk enquiries. Nine icon-led category tiles run across the top so a visitor who landed on a fittings ad can get to fittings without scrolling past cylinders. In September the page's design, content presentation, imagery and CTA sections were refined again alongside the new SMC Brand page.

The page closes on a trust band rather than another product grid — genuine product, distributor pricing, selection support, delivery, the customer base and the ISO certification, with the enquiry address repeated underneath. It's the last thing a visitor sees before deciding whether to write the email.

SMC, twice: the Brand page

The distributor page answers "can you quote this part?". The new SMC Brand page answers the question before it: "what does SMC make, and where does it fit?". So it was built with a completely different layout and visual direction from the distributor page — in SMC's own blue, white and black — leading with product imagery and hero sections, then industry applications and technology highlights, and only then the enquiry and CTA sections.

Both SMC pages were optimised together for responsive behaviour, real product images, enquiry and contact integration, SEO details and mobile layout, and validated after deployment.

IFM: the long one

IFM is the deepest of the brand pages and the page reflects it. Ten anchored sections — sensors, process sensors, IO-Link and communication, condition monitoring, vision and identification, safety, industrial communication, mobile machines, display and illuminate, IIoT, power and accessories — with a sticky anchor nav so a visitor who arrived on a condition-monitoring keyword can jump straight there instead of scrolling forty cards.

Each card carries a category image, an In stock badge, a one-line description and two capability bullets: Up to SIL 3 / PL e, Calorimetric & magnetic types, IP69K rated. That's the level of detail that decides whether a sensor is even a candidate, and putting it on the card saves the enquiry that only exists to ask it.

The enquiry band repeats between sections rather than sitting only at the bottom, because the page is long enough that a visitor may make their decision at section three. It closes on the same offer as Siemens: send a part number, a quantity or an application, get a quotation — with email named as the preferred route for accuracy and WhatsApp as the fast one.

See the IFM page — it's the clearest demonstration of the pattern at scale.

Four identities, on purpose

The storefront has its own look. Siemens is teal with a monospaced technical voice. SMC Distributor is deep blue with soft-cornered cards and a warmer one; SMC Brand is blue, white and black with a product-and-applications story. IFM runs on its own palette with image-led category cards and stock badges. A visitor arriving from an ad for one manufacturer should land somewhere that reads as that manufacturer's corner of the business, and should be in no doubt they've reached a page about that brand specifically rather than a general catalogue that happens to carry it.

All four are page templates inside the same Shopify theme, so the header, cart, chat agent and footer come along unchanged — and they carried straight through the Datum redesign. A new brand is a template and a palette, not a new build; where a brand deserves more, as SMC did, it gets a second page with its own layout.