The payment gateway was the obvious suspect. It was also innocent.

The first completed order made the report confusing: money could be authorised while the customer still saw a frozen button. A browser trace showed that the first checkout request returned successfully. The second and third requests came from the theme itself, after WooCommerce recalculated shipping for a changed postcode.

Inside the child theme, every updated_checkout event attached another anonymous submit handler. After a customer edited an address twice, three handlers were waiting. We reproduced that sequence on staging, removed the accumulated handlers and bound one namespaced listener to WooCommerce’s supported event bus. The missing email was a second fault, not part of checkout: a stalled Action Scheduler job was holding the transactional queue. We cleared it separately, replayed test messages and released only the child-theme patch.

The iPhone was not the cause. It merely made the race visible.

On a fast desktop both cart drawers painted almost on top of each other, so the defect looked like a small flicker. Network throttling exposed two separate POST requests: the bundle widget sent one, then the theme’s delegated submit handler sent the same variant again. Tracking was duplicated a second way — once on button click and again when the drawer received cart:updated.

Rather than special-case the widget, we gave standard product forms and bundle forms one addCartLines function. It became the only place allowed to mutate the cart. After Shopify accepted the request, the adapter emitted one cart:changed event with a request ID. The drawer refreshed from that event and GTM used the same ID for deduplication. We then ran variants, bundles, discounts, sold-out states and rapid double taps through the same path.

The screenshot matched Figma. The page did not behave like a page.

The desktop composition was accurate because its main wrapper was exactly 1180 pixels wide and each card was exactly 373 pixels. At narrower widths, the build scaled and shifted that fixed canvas. The usual 375-pixel phone preview happened to hide the overflow; a 393-pixel device plus a longer translated heading revealed it immediately.

We first moved repeated testimonial and feature content into Webflow CMS so layout could be tested against realistic short, long and missing values. Then the fixed canvas became a fluid container, cards became a content-aware grid and type/spacing moved to clamp-based tokens. Instead of drawing another set of breakpoint exceptions, we defined what each component should do when space or content changed. The handoff included a CMS editing pass with the campaign manager, not just screenshots from our account.

The reports disagreed because each platform was measuring a different moment.

GTM Preview showed generate_lead as soon as the button was clicked — even when browser validation rejected the form. A second container, pasted into one Webflow template months earlier, produced duplicate page and Meta events. Google Ads looked lower because its tag respected the current consent state while the older Meta tag did not follow the same trigger path.

We removed the template-level duplicate, documented the remaining container and stopped treating a click as a business result. The form integration now returns a submission ID only after HubSpot accepts the lead. That confirmation calls one analytics function with form ID, page path and the non-personal submission ID. We tested accepted, validation-error, CRM-timeout, consented and denied scenarios in GTM Preview and GA4 DebugView, then recorded the event contract for future campaign tags.

Incognito worked perfectly — which was the clue, not proof that production was fine.

The component read localStorage while creating its initial state. On the server, localStorage does not exist, so HTML was rendered with monthly prices. A returning visitor’s browser immediately rendered annual prices from saved state. React received two different trees and warned during hydration; depending on timing, the switch then snapped back to the server value.

The earlier implementation marked the entire pricing section use client just to support one toggle. We moved plan content back to the server and isolated the interactive preference in a small BillingCycleToggle. Server and browser now begin with the same monthly structure; after hydration, an effect applies the saved preference. A returning-user test was added alongside fresh-session, direct-navigation, refresh and keyboard cases. That both fixed the error and removed unnecessary plan markup from the client bundle.

The update count looked frightening. The status report told us where to look first.

Most plugins could be updated normally once dependencies were ordered. The real risk sat in the child theme: its review-order.php override came from an old WooCommerce version and read a product’s public price property directly. The current plugin had kept a compatibility layer, but the planned update removed the behaviour that made the template appear to work.

We built a recoverable staging copy, crawled critical journeys and grouped changes by dependency rather than age. Before the WooCommerce batch, the override was reduced to the part the design actually needed and switched to the supported cart subtotal API. Updates then ran through committed WP-CLI batch scripts, each preceded by a database export and followed by the same checkout, account, search, lead and metadata smoke tests. When a minor plugin failed, set -e stopped that batch before later changes obscured the cause.

The green success message was optimistic UI applied to the wrong kind of action.

The Framer override started a request to a legacy relay and immediately set the form to sent. It did not await the promise or inspect the response. The relay itself could return 200 after queueing work even when HubSpot later answered 429. Visitors saw success in every one of those paths, and a manual retry could create two contacts if the first queue eventually recovered.

We kept the visible component but replaced its submission boundary. The browser sends a generated idempotency key to a small server endpoint, which validates an allow-list of fields and calls HubSpot. A delivery result is stored against that key. If a slow connection repeats the request, the endpoint returns the original result rather than creating another contact. Framer shows success only after a confirmed response; temporary failure keeps the entered values and presents a retry action. Logs retain the delivery ID and status, not the visitor’s full message.

The old spreadsheet contained URLs, but it did not contain a migration plan.

The sheet mixed live paths, UTM-decorated duplicates, trailing-slash variants and German/English pages. Several rows pointed to another old URL rather than a final destination. A catch-all rule attempted to make the report look clean by sending every unknown path to the homepage, including misspellings and genuinely removed content.

We combined the sheet with a crawl, indexed results and analytics landing pages, then assigned a disposition to each path: exact destination, pattern destination, intentionally gone or unresolved for content review. Redirect chains were flattened to one hop and locale stayed part of the matching key. The small edge handler normalises only the trailing slash, looks up an explicit destination and otherwise allows Webflow to return a truthful 404. After release, a second crawl checked status, final URL, canonical and campaign query preservation.

This was not a calendar widget. It was a distributed reservation flow.

The initial prototype called the booking API directly from a WordPress shortcode every time a visitor changed a date. It looked acceptable with one developer and one location. Under a realistic response delay, each filter change started another PHP request and occupied a web worker until the provider answered. A timeout returned an empty schedule, which the interface incorrectly presented as “No sessions available.” The API also returned UTC timestamps while each venue sold according to its local day; an evening workshop in one city appeared under tomorrow’s date on the website.

Before building checkout, we wrote a field map for venue, resource, session, capacity, optional equipment and deposit rules. Provider IDs were stored as stable identifiers; titles were display content only. A background queue imported the next booking window into dedicated plugin tables and normalised every timestamp with the venue’s IANA time zone. The public schedule read that local snapshot, showing its last successful sync time. When the provider slowed down, visitors saw slightly stale but labelled availability instead of a false empty state, while a queued refresh retried with backoff.

Checkout added a short capacity hold rather than creating the remote booking immediately. The hold ID travelled in WooCommerce order metadata. After payment, a signed job converted the hold into the provider reservation and saved the remote confirmation against the order. Provider webhooks invalidated affected sessions, but webhook delivery was not trusted as the only mechanism: a reconciliation job compared paid orders, local holds and remote bookings. We added an admin screen for failed syncs, manual retry and an audit trail so staff did not need server access to understand a discrepancy.

The difficult part was not importing the catalogue. It was making the import safe to repeat.

The first proof-of-concept treated product title and SKU as identity. Neither was stable: titles had changed over the years and several wholesale packs intentionally reused the retail SKU. When the script hit a Shopify rate limit and restarted, it could not tell which rows were already committed. It created another product, applied inventory to both and left the test store looking successful only at the total-count level.

We created a migration ledger keyed by immutable Lightspeed entity IDs. Every Shopify product, variant, customer and order received a source-system metafield, and every successful write recorded the source ID, Shopify ID, payload checksum and cursor position. The importer became idempotent: rerunning the same row updated the linked record only when its checksum changed. Writes were grouped around Shopify’s cost-based limits, and a dead-letter queue held records needing human mapping rather than allowing one malformed variant to stop the whole catalogue.

Data moved in rehearsed layers. The base import established catalogue, customers and historical orders in a development store. A custom Shopify app then handled ongoing warehouse inventory, translating location IDs and ignoring its own webhook echoes. Subscription records were mapped only after product and customer identities were stable; payment credentials were handled through the supported provider migration path rather than placed in export files. Wholesale rules became explicit company/catalog assignments, not tags interpreted by theme JavaScript.

For launch, we ran a delta import, compared entity and inventory reconciliation reports, then placed only the old checkout into a short maintenance window. Orders created since the rehearsal were imported from the saved cursor, DNS and payment checks were completed, and the warehouse integration changed its destination after Shopify inventory matched the signed-off report. The rollback plan kept the old storefront read-only and preserved the final source cursor, so returning did not mean guessing which system held the latest order.

The visible calculator was the smallest part of the feature.

The spreadsheet was not copied directly into code. We first turned its rows into named business rules and asked sales to resolve contradictions: one tab applied the volume discount before the regional minimum, another applied it after. Approved examples became fixtures with expected totals. Marketing copy, help text and module descriptions remained Webflow CMS content; the embedded application received only stable option IDs from data attributes.

The early browser prototype incremented a running total whenever a checkbox changed. Going Back and Next replayed change handlers and added the same onboarding option again. It also trusted prices stored in HTML, which meant a visitor could edit data-price and submit any total. We replaced the accumulator with a pure quote engine: every screen derives a fresh result from the complete normalized configuration. The browser displays an estimate, but the server validates the same option IDs, recalculates from its own catalog version and signs the resulting quote.

Share links contain only versioned configuration — plan, quantity band, regions and module IDs. Contact fields never enter the URL. Opening a link restores the steps and asks for contact information only when the visitor requests the PDF or sales follow-up. HubSpot receives both human-readable choices and the signed quote ID, so a rep can reopen the exact server-calculated version even after marketing updates website copy.

We added keyboard navigation, inline rule explanations and a summary that announces price changes without moving focus. Analytics records step name, selected option IDs and completion state, but no contact values. The release included spreadsheet fixtures, API contract tests, incompatible-option tests and a “catalog version expired” path that recalculates an old shared link instead of silently showing stale numbers.

A return is not a form submission. It is a stateful workflow with money at the end.

The first mock-up checked only order age and a final-sale tag. That failed as soon as one order contained both eligible and ineligible lines, or when the delivery date differed from the order date. Policy also varied by market: one region counted calendar days from delivery, another allowed an extended holiday window, and damaged items required evidence even when otherwise ineligible for a normal return.

We modelled eligibility as a pure decision per line item. Inputs include delivery timestamp, market, product policy class, quantity already returned, requested resolution and reason. The output is not just true or false; it contains allowed quantity, permitted resolutions, approval requirement and a customer-safe explanation code. That same result controls the account UI and is recalculated by the server when a request is submitted, so hiding a disabled button cannot bypass policy.

Photo evidence uses short-lived signed upload URLs scoped to the authenticated customer, order and return draft. Files are quarantined, type-checked from content rather than filename, scanned and attached to the draft only after verification. The browser never receives warehouse credentials and support never downloads attachments from email.

Submitting an eligible draft creates an RMA state machine. Low-risk returns can request a label from the 3PL; high-value or exception cases enter needs_review. Warehouse webhooks are signature-checked and stored by event ID before processing. Only allowed transitions — requested to in_transit to received to inspected to refunded — can run side effects. Duplicate received events therefore cannot issue two refunds. Customers and support read the same timeline, with internal notes kept separate from customer-visible messages.