The vendor connector I was using could only work with one Shopify store at a time.

That became a problem as soon as I wanted to work across four markets.

The data existed.

The API existed.

The connector was the constraint.

Could I connect to all four stores through Shopify’s API instead?

I didn’t know the implementation path yet.

So I used Claude Code to explore what was technically possible and work through the implementation with me.

I started with the requirement:

One workflow that could work across four Shopify stores.

From there, I used Claude Code as a technical collaborator to investigate the API, work through the architecture, generate and modify code, explain unfamiliar concepts, and debug the implementation step by step.

The resulting data layer covers 4 stores, 13 tools and 3,463 lines, and includes:

• OAuth client credentials
• automatic token refresh
• Keychain-managed secrets
• concurrent multi-store requests
• per-store failure isolation
• read-only defaults
• explicit write access per store

Claude helped me:

• explore the Shopify API
• work through authentication
• propose implementation approaches
• generate and modify code
• debug errors
• explain technical concepts as I went
• iterate on the architecture

I didn’t need to know every implementation detail before I started.

I needed to know what I wanted the system to do, what constraints mattered, and how to evaluate whether the solution was actually working.

The important decisions stayed with me:

• What problem am I solving?
• What should the system do?
• What constraints matter?
• Is this approach actually better than the existing workflow?
• What should be read-only?
• What happens when one store fails?
• How do I know the output is trustworthy?

The technical barrier wasn’t simply removed.

It changed.

Instead of asking “Do I know how to build this?” I could ask “Is this possible, and can I work my way to the implementation?”

That changed what I was able to attempt.

The one-store limitation was no longer the boundary of what I could analyse or automate.

I now had a reusable layer that could work across all four Shopify stores from a single workflow.

That opened up a different class of analysis and automation.

You don’t need to know how to build something before you can decide that it should exist.

AI made the implementation barrier lower.

It did not remove the need for judgement.

Stock decisions depended on information owned by different teams and maintained in different places. Each week required downloading files, cleaning data, reconciling hundreds of SKUs, and weighing competing requirements:

• What inventory is available now?
• What is selling, and at what rate?
• Which inbound stock is confirmed, and when will it arrive?
• What stock is already committed to wholesale?
• What buffer must remain protected?
• Where have recent stockouts hidden unmet demand?

The task was not simply to calculate a number. It was to make a defensible allocation decision from incomplete, changing operational data.

Could this weekly process become a system that produced consistent recommendations, and knew when it could not safely produce one?

The workflow combines:

InventoryDemand velocityInbound timingWholesale commitmentsStock buffersAvailability gapsValidated stock decision

It produces a structured view of demand coverage and availability by SKU, helping teams identify where stock should be protected, allocated, or reprioritised.

The key requirement was reliability.

Instead of trusting spreadsheet headers alone, the workflow validates expected columns by their formula signatures and structure. If a source file has changed, contains an unexpected calculation, or cannot be interpreted with confidence, the workflow stops and flags the issue for review.

That prevents a familiar automation failure mode: producing a plausible-looking answer from the wrong input.

A system that can say “I can’t safely answer this” is more valuable than one that confidently produces the wrong number.

AI supports the analytical workflow by helping interpret source data, maintain the process, and surface patterns across multiple inputs.

It does not replace the core stock calculations or validation rules. Critical calculations remain deterministic, traceable, and subject to explicit checks.

Before, the weekly stock process could show what inventory was on hand. It could not reliably show where future demand was at risk, where commercial demand had been omitted, or where action could be taken immediately.

The workflow changed that. Each week, it gave the team a validated view of three questions:

1. Where are we likely to lose demand?

   It identified forecast demand that could not be served with currently available stock.

2. What demand is missing from the decision?

   It surfaced commercial demand that had previously not been represented in stock-allocation planning.

3. What can we recover now?

   It identified immediately actionable opportunities, allowing the team to prioritise stock without waiting for further inbound inventory.

This shifted the weekly process from reconciling spreadsheets to making explicit trade-offs between demand, stock protection, wholesale commitments, and availability.

The broader workflow removed approximately 200 hours of manual work annually.

Financial values are withheld to protect confidential company data. This case study focuses on the decision system and the operational capability it created.

The difficult part was not automating a spreadsheet.

It was defining the decision itself: which inputs belonged in it, which constraints could not be compromised, and when the available data was insufficient to make a reliable recommendation.

Customers arriving from advertising were landing directly on a collection page rather than entering through the wider site.

The page showed products, but did not answer the questions a new visitor needed answered before selecting one:

• What is this collection for?
• Which product is right for me?
• What makes the products different?
• Why should I trust this choice?

To get that context, visitors had to open individual product pages, compare options themselves, or leave the site.

Where were we asking high-intent customers to do unnecessary work before they could make a product decision?

I combined:

• Shopify traffic and conversion performance
• funnel behaviour from collection-page landing through to purchase
• heatmaps and session recordings
• device-level behaviour, particularly mobile
• paid-traffic landing-page performance

The pattern was consistent: visitors were reaching the collection page with interest, but the page did not give them enough context to move confidently from browsing to product selection.

Session recordings showed friction early in the journey: customers scanned the collection, hesitated between products, and needed additional navigation to understand what they were considering. The problem was not a lack of traffic; it was a lack of decision support at the point of arrival.

I translated the research into prioritised UX and merchandising improvements for the collection experience.

The work focused on bringing product context closer to the decision point: for example, clearer collection-level guidance, more useful product differentiation, and a more intentional path from campaign landing page to product selection.

I then led delivery with the external web agency, maintaining a backlog of 20+ website improvements and bug fixes. Each brief included:

• the commercial rationale and supporting evidence
• the customer problem being addressed
• expected impact and priority
• before-and-after UX references
• clear implementation and acceptance requirements

This kept the work connected to customer behaviour rather than treating it as a series of isolated design requests.

For the updated collection experience in New Zealand, over the first month after launch:

Conversion optimisation is not always about making the case more persuasive.

Sometimes the highest-value change is simpler: remove the unnecessary work between “I’m interested” and “I understand which product is right for me.”

Planning limited editions had often relied on intuition, recent best sellers, and individual market feedback.

Those inputs mattered, but they did not answer a more useful question: which products were likely not only to sell, but to create a valuable next customer action?

Can a customer’s first purchase help predict what they are likely to buy next?

I used three years of sales and customer data across markets to examine:

• product velocity and sell-through
• first-to-second-purchase pathways
• repeat-purchase behaviour
• customer spend and return patterns
• model and colour performance
• differences in product behaviour between markets
• previous limited-edition and collaboration performance

Rather than looking only at total units sold, I followed customer purchase sequences: what they bought first, whether they returned, and what they chose next.

The analysis produced several patterns worth investigating, but none was robust enough to treat as a predictive planning rule.

I tested whether first product, order value, model, or colour could help explain a customer’s later purchase behaviour. When those relationships were examined across markets, customer cohorts, and the available purchase window, they did not remain sufficiently consistent or meaningful to support deterministic product or marketing decisions.

This distinction mattered. An observation in one cut of the data can be useful for further investigation, but it should not be treated as a commercial rule unless it holds under appropriate scrutiny.

The goal was not to create a more elaborate sales report. It was to give product and marketing teams a better way to evaluate prospective releases.

I translated the work into a planning framework that considered:

Demand potentialProduct velocityRepeat-purchase contributionCustomer valueMarket fitColour / model historyPlanning recommendation

This gave product and marketing a consistent way to weigh a prospective release, and an explicit record of which inputs were evidence and which were judgement.

AI helped accelerate exploratory work: inspecting data structures, generating candidate cohort cuts, documenting logic, and flagging unusual relationships for review.

But AI could not decide whether a pattern should influence the next limited-edition range.

For example, a purchase sequence might suggest that customers who bought one category often returned for another. That alone does not explain why. The relationship could reflect genuine product affinity, a colour trend, seasonal availability, a campaign effect, or a market-specific behaviour.

My role was to define the commercial question, test whether the pattern held in context, decide which signals were strong enough to use, and turn those findings into recommendations for product, merchandising, and marketing teams.

The work gave future product and marketing discussions a shared evidence base. Rather than asking only, “What sold most?”, teams could ask:

• Which products are likely to acquire the right customers?
• Which products are more likely to contribute to a second purchase?
• Which colour, model, and market signals are robust enough to plan around?
• Where should evidence inform the decision, and where should judgement remain explicit?

The most useful question was not, “What sold the most?”

It was, “What does this product teach us about the customer relationship that follows?”