• Shopify Markets overview and benefits

• Technical architecture and challenges of implementing Markets

• Market-aware shopper experience and personalization

• Data and marketing strategies for global merchants

• Future AI integrations and product roadmap

Chapters

00:00 Introduction to Shopify Markets

02:58 Understanding Shopify Markets

05:27 Shopper Experience in Global Markets

08:17 Technical Challenges and Solutions

10:55 Marketing Insights for Merchants

13:55 Product Challenges and Edge Cases

16:46 Building for Scale and Complexity

19:13 Future of Market Support

22:12 Advice for Developers and Merchants

Resources

Shopify Markets Overview
Swym’s Shopify Markets details

Note from the Author
This document reflects my perspective on how we built and enabled the capability, not really a how-to-use. If you are looking to try it out or looking for our product documentation or support features, our web portal is the best place to start or try our app on your store.

There’s a silent conversation happening on every storefront, every single day.

It’s the moment a shopper hovers over an item, pauses, and clicks that heart button. They aren’t ready to buy - not yet - but they’ve just raised their hand. They’ve signaled intent.

For years, we at Swym have tracked this social proof (the number of times a product is added to a wishlist) and enabled access via APIs. We knew which products were simmering just below the surface of a “Best Seller” list. Quite a few merchants leveraged it but not without limitations. Eg: a product details page will show just one product’s social proof, but a collection page needs to show all products in that all collection. That meant there were more API calls to pull and render it. Plus this wasn’t easily available to build customizations that are directly connected to the catalog filtering. It was a “Swym capability,” not a entirely general “Storefront reality.”

By making this nugget available on Shopify Product Metafields, it makes many use cases previously complicated to a simpler usage pattern and not compromised based on the implementation philosophy (if you know Shopify, you know there are infinite options to implement the same thing and usually most of them don’t end up with efficiency and speed goals the implementation starts with)

Start with why

Like usual, we start with why. So let me dive a bit deeper

Ecommerce business philosophy is somewhat obsessed with “Best Sellers.” It’s one of the loudest metric out there. But sales data only tells us what happened yesterday.

The Wishlist Social Proof (aka Wishlist Social Count) tells us what is going to happen tomorrow. By syncing this intent data point natively into Shopify Metafields, this a way to listen to the Most Desired products - the ones that are trending in the hearts of shoppers before they get to the checkout line eventually.

Why should Shopify Native matter?

This is something that needs context more than technicality. So when we sat down to build this, we had plenty of merchants leveraging this social proof in their experience flows. But it was nowhere straightforward. Clearly we need to multiple the craft of the modern developer, not add more complexities

By pushing into a metafield, we’ve enabled access to the data from an API call to a native Shopify attribute, ie it’s available where Shopify renders the rest of the ecommerce context that the merchant wants.

So it may not be obvious, but the answer goes far beyond just Storefront Efficiency (though that’s a huge part of it).

1. Render at Liquid speed: Think of the metafield as an extended edge cache for the Swym API (ie render first, refresh later if needed). So by storing these values directly on the Shopify Product object, the storefront load doesn’t have to make any additional API call to finish rendering.
   eg: Reference to the social count directly on a Liquid theme file
   
   {{ product.metafields.swym_wishlist.wishlist_social_count }}

   This is critical for rendering social counts on Collection Pages where there may be 50+ products displayed at once. The result? No layout shift, no “loading” spinners, and zero impact to PageSpeed scores due to any missed implementation constraint. I am sure we don’t have to say this, but this is a huge dev experience lever.

2. Native Automation: As the data point is available inside Shopify, it is accessible on tools like Shopify Flow. It opens up ideas we haven’t even thought about, like using a flow trigger workflow based on the change in soccial count of a product. eg: Do something cool when product.wishlist_social_count > 1000.

3. AI Readiness: I am sure pretty much every Shopify admin is already using Shopify Sidekick. So now that can also parse this “popularity” construct to help make better decisions, be it merchandising or support cool segments or widgets to the storefront experience.

4. The future - Seamless Ecosystem Enablement: This essentially normalizes access to Swym for theme developers, agencies, or other apps in the ecommerce tech stack (like search provider or loyalty program). This means the experiences are faster to build (low complexity), cheaper to maintain (we maintain it!), and require little to no API work.

The Technical “How-To”

We push the Social Count to our namespace to enable ease of use.

Using it in Liquid

Displaying this on Product Details Page (PDP) or Collection Page is now literally one Liquid render:

Sample Code snippet

{% if product.metafields.swym_wishlist.wishlist_social_count > 10 %}
  <span class="swym-wishlist-plus-badge">
    🔥 {{ product.metafields.swym_wishlist.wishlist_social_count }} people want this!
  </span>
{% endif %}

The Power of the TOML: Seamless Integration

Sure it’s easy to build something, but to deploy it at our scale (50K and growing) requires an equally reliable way to deploy and monitor. Not to mention to rollback if things go awry. So we leveraged Metafield Definitions directly within the app' TOML configuration. giving our silent tip of the hat to Shopify’s evolving dev experience.

With this incredible automation powered by the Shopify platform itself, it’s a big chunk off our todo-list. Literally, we pushed these standardized definitions to our all of those 50K+ merchants without a hitch.

It’s clean, it’s standardized and it’s simple.

[product.metafields.app.wishlist_social_count]
name = “Wishlist Social Count”
description = “The number of times this product has been added to a shopper’s wishlist”
type = “number_integer”
capabilities.admin_filterable = true
access.customer_account = “read”
access.storefront = “public_read”
access.admin = “merchant_read”

The above was the seemingly simple part, in the background we manage the scale per merchant per intent update through our systems. We deliberated on efficient ways on doing this sync. Here is a small brief on what we discussed

• When’s the best time to sync a product?

• What triggers should initiate a refresh?

• What’s a good SLA?

• How do we measure the above-mentioned SLA?

• How do we “onboard” past social proof for existing scale?

• This one is super tricky - How do we manage retries and rate limits? (both internal services and Shopify’s API rate limits)

Without going into the details, we have decisions and factors considered into it. We’ll reassess and upgrade our approach as we learn more or if factors change/new factors enter the picture

Intent proof finding voice

1. Automated Merchandising with Shopify Flow

Set up a workflow that monitors wishlist social counts. If a product’s social count hits a “Viral” threshold (For example, a social count value of 100), have Flow automatically add it to a “Trending Now” collection or tag it for a social media spotlight.

2. Automated Urgency with Shopify Flow

Imagine a workflow where, if a product’s Social Count hits 100 but inventory drops below 10, an automatic “High Demand” tag is added to the product.

3. AI-Generated Badges with Sidekick

Use Shopify Sidekick to effortlessly design UI elements based on it, surface it any which way.

4. Collection Sort

Go beyond “Best Selling” or “Price: Low to High.” Create a “Most Wanted” sort option. This allows shoppers to filter the catalog by what the community is currently eyeing, creating a trend-driven shopping experience that feels real and alive.

The Heart of the Story

We didn’t enable this sync just to move numbers from point A to point B. We built it because we believe the most successful experiences are the ones that connect best products with the shoppers in the best way possible - ie the experiences that are best at listening to what the shopper “wants”.

We can see the crowd gathering from our end and now, so can our merchants and their shoppers as easily as we do.

P.S: Here is our product documentation again in case you want to try it out

In the world of software engineering, growth is a good problem to have. But with growth in services, code, and people comes its inevitable companion: complexity. At Swym, we undertook a significant project to tackle this head-on by merging our numerous internal Clojure library repositories into a single, unified repo.

This wasn't just a technical exercise in tidying up. It was a strategic move to simplify our systems, reduce cognitive overhead for our engineers, and pave the way for a more efficient future. This is the story of that project—our motivations, our strategy, our risks, and the lessons we learned along the way.

The Tipping Point: Why We Had to Change

Like many growing companies, our architecture evolved. The initial choice to have separate repositories for different services and libraries made sense at the time, but as we scaled, this separation started to create friction. The real-world trigger for the merge was the sheer complexity involved in what should have been simple tasks: needing to build, deploy, test, and manage numerous components for a single function was becoming a bottleneck. The cost of adding value was becoming too high compared to the value itself.

Our stack is built on Clojure, a powerful and dynamic language running on the JVM. By its nature, Clojure allows for a lot of flexibility through guidelines rather than rigid rules. While this is a strength, it also meant that over time, inconsistencies grew across our many repos. This lack of a singular, enforceable guideline was a constant challenge.

There was also a subtle, forward-looking trigger: a centralised context would be hugely beneficial for the AI tools we are increasingly relying on. While not the sole reason, it was a necessary condition to unlock their full potential. We knew we had to re-evaluate our architectural choices to get ready for the future.

The Game Plan: A "Band-Aid Rip-Off"

We had attempted this before and paused, knowing the problem had merit but that the timing wasn't right. This time, we had a clear strategy. Aravind Baskaran, who spearheaded the initiative, called it the "band-aid rip-off" approach.

The core idea was to make the change swiftly and cleanly, focusing only on simplifying deployment and structure without altering any existing functionality in the first phase. All the code would move, the structure would change, but the underlying logic would remain untouched.

This approach had a few key principles:

• No Functionality Changes: This was critical. By ensuring the core logic was the same, we could be confident that, with baseline tests passing, the system would behave as expected.

• Active Monitoring is Key: After the merge, we had to be incredibly watchful. We paid close attention to key metrics like build and deploy times—which we expected to be reduced by 50-60%—but also watched for any negative runtime implications.

• A Stable Technical Foundation: A key technical goal was to have a solid map of all our component versions—from the JVM and Clojure itself to our Kubernetes environment variables—to ensure a smooth and predictable rollout.

Navigating the Risks: Don't Stop the Train

A project of this scale is not without its risks. The biggest fear was the point of no return. Aravind likened it to "stopping and reversing a large train". An undertaking this large had to be atomic—it was either done or not done, with no room for a "half-done" intermediate state.

Other significant risks included:

• Lack of Signals: The fear that even with testing, we might not have adequate signals to detect subtle issues once the changes hit our production Kubernetes environments.

• Feature Release Conflicts: We are constantly shipping new features. Trying to coordinate this merge with twenty other feature releases could have created a processing nightmare.

To mitigate this, the project was given a critical "shelf life". It had to be completed within a specific, tight time window to avoid causing more damage than it solved. If it took too long, the disruption to business requirements would outweigh the benefits. We carefully planned this window to execute the project with minimal disruption, ensuring no other deployments proceeded without a "green flag" from the merge team.

Lessons from the Trenches: Our Key Takeaways

This project was a tremendous learning experience. Here are our biggest takeaways for any team considering a similar endeavor.

1. This is Not a Side Project

Our previous attempts had stalled because the work was treated as a "side experiment". The most significant learning was that for a project of this magnitude to succeed, it cannot be a side project. It has to be the project. It requires focus and commitment to get it done.

2. Empower a Single Driver

While input from many is crucial, the execution needs a single, responsible owner to avoid "room for committee" based negotiations. We found success by letting the person who wants to take it forward build the proposal and enabling them to succeed, knowing they will be responsible for making and fixing mistakes along the way.

3. Embrace Your Tools (and Your Team)

The AI tooling available today significantly reduced the manual grunt work that would have made this project much more arduous in the past. But tools are only part of the equation. The project's success was driven by the team's conviction that this was a necessary pain point to address and by their confidence in the system's scalability and reliability.

4. The Merge is a Foundation for the Future

This project wasn't just about cleaning up the past; it was about building a better future. By bringing our Clojure code together, we now have the closest shot at developing and enforcing community-driven guidelines and standards internally. It allows our internal community to grow and build its legacy in terms of how we build software in 2025 and beyond.

The Journey to Simplicity Continues

The great library merge is complete, but it marks a beginning, not an end. Our journey toward simplicity is ongoing. Over the next few weeks and months, we will be closely observing the ripple effects of this change—both good and bad—to continue learning and refining our processes. The immediate next steps involve improving our monitoring signals so we can understand system health without digging into every detail, making our operations even more efficient.

This merge has given us more than just a cleaner codebase; it has provided a simplified, stable foundation. It enables us to finally attack the larger opportunities we had previously put on hold. By taking on this challenge, we've not only improved our day-to-day development reality but have also reaffirmed a core engineering principle: sometimes, to go faster, you first have to simplify.

Reflections from 2026

Looking back from early 2026, the “Great Library Merge” of August 2025 has proven to be a watershed moment for our engineering velocity. The most immediate win was the dramatic slash in overhead; our build and deployment times dropped, transforming what used to be a sluggish bottleneck into a streamlined, rapid-fire process. However, the most strategic advantage emerged in our AI integration. By consolidating our entire Clojure ecosystem into a single, unified source of truth, we provided our AI agents with a comprehensive, centralized context. This “one-stop shop” for code architecture has made it significantly easier to build agents that understand our entire system’s nuances without getting lost in repository sprawl. What started as a cleanup project has become the essential foundation for our AI-driven future.

Navigating Change: Inside Swym’s Evolving Engineering Culture

In this episode, Rishin, Aravind and I discuss the significant shifts happening within Swym’s engineering practices, emphasizing the move towards more autonomous, signal-driven decision-making powered by AI and automation. They explore how these changes impact daily routines, team ownership, and future growth strategies in a rapidly transforming tech landscape.

Key topics:

• Transition from traditional product-defined workflows to the “engineering pulse” approach

• The role of daily rituals and automation in aligning teams with impact-driven goals

• How AI is revolutionizing repetitive tasks in infrastructure and code development

• New metrics and signals replacing old success measures

• The importance of ownership, autonomy, and deep work in an AI-enhanced environment

• Future of engineering careers in a fast-evolving AI-driven world

• The significance of continuous learning, experimentation, and honest reflection

Timestamps:

00:00 - Introduction to Swym’s internal shift towards the “engineering pulse”
02:31 - The importance of daily rituals and reducing hype with consistent routines
04:48 - How metrics are evolving and the shift in success signals
06:19 - Deep impact, automation, and focusing on what truly matters
09:03 - Making the abstract concrete: transferring learning and the power of repetition
12:19 - The future of engineer careers with AI and ownership of outcomes
15:01 - AI as a stepping stone for rapid experimentation and deep work
17:16 - Changing roles, titles, and the focus on intent over seniority
18:39 - Envisioning 2026: key truths about the evolving software landscape
21:14 - Preparing for exponential growth and strategic positioning
24:50 - The importance of discipline, boring routines, and continuous iteration
28:27 - Reflecting on company metrics, growth expectations, and upcoming targets
29:39 - Closing thoughts on ongoing support, transparency, and future initiatives

Resources & Links:

• Swym Official Website

• Want to join us - Read below !

Note:

This conversation reflects Swym’s internal evolution and its strategic emphasis on automation, ownership, and agility amid technological shifts driven by AI advancements.

Note from the Author
This document reflects my perspective on how Swym functions as a Customer Journey Management engine. It is shaped by my understanding of the product, its design philosophy, and how I see journeys being modeled and executed in practice.

It is my attempt to explain the underlying ideas in a way that connects customer experience thinking with systems that operate at scale.

If you are looking for our product documentation or support features, our web portal is the best place to start or try our app on your store.

Context is King: Navigating the Fine Line Between Boosting Sales and Losing Trust

For any merchant getting started with their online store, there are too many apps out there waiting to help you take your sales through the roof and make your business boom. But why isn’t every merchant successful then? A sword is only as good as the person who wields it; the merchant decides whether it will kill or create their business.

One merchant might track specific points of their customer’s interactions on their page and send out minimal and targeted emails, which enhances both the customer’s experience with their brand and also boosts their business. Another sends out emails for every price drop and every discount on their store, and eventually end up in their customers’ spam folder or even worse, get unsubscribed.

The difference here is perception. A merchant must ensure a customer’s overall view of a brand stays positive because the loss of trust is irreversible.

A real-life instance I found while researching customer trust is a complete disconnect between how messaging without context (or in the wrong context) can end up being pretty bad. In 2017, Adidas sent an automated email to Boston Marathon participants with the subject line, “Congrats, you survived the Boston Marathon.” The intent was positive, but the message ignored critical context. Just a few years earlier, the Boston Marathon had been the site of a deadly bombing. What should have been celebratory came across as insensitive, forcing Adidas to issue a public apology.

Read more here on how they recovered from that.

Tools lacking context can create moments where the brand value erodes, needing additional effort to recover.

What is a Customer Journey Map and why does it matter?

A Customer Journey Map (CJM) is a visual representation of a customer’s experience with your brand. It provides an understanding of needs and concerns that either motivate or inhibit action. While we often discuss these as four distinct phases, it is important to remember that human behavior is rarely linear. Customers often loop back to previous stages or jump ahead unexpectedly. For this discussion, we will look at these four primary phases:

Discovery Phase

The customer becomes aware of a problem or desire and first encounters your brand through ads, content, word-of-mouth, or organic discovery.

Take Alice, she uses the local train to commute to work every day. She gets tired of the crowd, discomfort, and delays while using public transport, and the idea of buying a car pops into her head as a solution to the problems of time, comfort, and convenience.

Research Phase

The customer compares options, evaluates credibility, reads reviews, and looks for signals of trust, value, and relevance before committing.

Alice compares car models, prices, fuel types, EMI options, reviews, maintenance costs, and resale value while shortlisting brands that fit their budget and lifestyle.

Decision Phase

The customer decides to purchase based on price, confidence, timing, and experience, converting intent into action.

As Alice visits multiple car showrooms, most offer similar prices and features. One dealer, however, stands out: transparent pricing, flexible financing, a smooth test-drive experience, and timely follow-ups without pressure.

At this point, Alice isn’t choosing a car anymore; she’s choosing who she trusts. That confidence tips the decision, and she makes the purchase.

Delight Phase

Post-purchase experiences reinforce trust, build loyalty, and turn customers into repeat buyers and advocates through thoughtful communication and value.

After the purchase, Alice’s experience with the brand truly begins. Smooth delivery, clear onboarding, timely service reminders, responsive support, and thoughtful follow-ups reinforce her decision. Over time, consistent positive experiences turn satisfaction into trust, and trust into loyalty and recommendations.

The Non-Linear Loop

In reality, a customer might be in the Research phase and suddenly get pulled back into Discovery by a new technology, or they might stay in a loop between Research and Decision for months.

External factors also play a massive role in providing context. For example, a car dealership might see a sudden price drop or a spike in promotions. Is it just a sale, or is it because a heavy snowstorm has stopped everyone from driving, forcing the dealer to adjust? A merchant who understands that “it’s snowing, so no one is thinking about test drives” can adjust their messaging to be more empathetic rather than just pushy.

How to Make a Customer Journey Map?

Define a Persona (a generic customer)

Create a representative customer profile that reflects your target audience’s goals, behavior, and constraints.

Define the Journey Phases

Outline the key stages of interaction with your brand (Discovery, Research, Decision, Delight).

Map the Steps in Each Phase

Identify the actions the customer takes at every stage.

Analyze Each Phase

• Questions in the customer’s mind

• Thoughts and emotions driving decisions

• Pain points or friction

• Opportunities to improve the experience

How to use a CJM with E-commerce Tools?

In each phase of the map, the tool we use differs based on its relevance and effectiveness. Simple, you can’t use a screwdriver to write poems.

In the previous step, we analyzed the customer’s mindset at each phase of the journey. Use that understanding to decide which tools genuinely help the customer move through that phase with ease.

The goal isn’t to use more tools, but to use the right tool at the right moment, and sometimes, to use none at all.

For example, an email tool might be used in one phase to run a broad, targeted marketing campaign, while in another it may simply send a single price-drop alert to a customer who has already shown clear interest in a product.

Hence, the same tool can be used multiple times across a journey, but in very different ways.

The CJM Engine

Understanding a journey is one thing, but executing it consistently at scale is another. Imagine a sous chef in a restaurant. They don’t invent the recipes; they focus on consistent execution. They wait for orders, observe the kitchen, and react when the time is right. They coordinate the stoves, ovens, and knives using only what the dish needs.

A CJM engine works the same way. It executes the journey by following intent with judgment. The merchant defines the “recipe” (the instructions of when and what to do) and the engine follows it.

The Recipe

For the engine to work, the recipe must be clear. This is your data model: a structured description of what starts a journey, what conditions matter, and when it should end.

Just like in a kitchen, vague recipes lead to inconsistent dishes.
A well-defined recipe allows the engine to execute journeys reliably, repeatedly, and at scale.

This is how intent becomes something software can understand and follow.

Example: A Shoe Brand’s Customer Journey Recipe

Persona:
A customer looking for comfortable running shoes for daily workouts.

Discovery
The customer sees a social media ad about lightweight running shoes and visits the brand’s website to browse.

Research
They read reviews, compare models, check sizing guides, and shortlist one pair. They add the shoes to their wishlist.

Decision
A few days later, the price drops slightly. The customer receives a single, well-timed notification highlighting the offer and free returns. They complete the purchase.

Delight
After delivery, the brand sends care tips, running advice, and a reminder to review the product. Over time, the customer receives loyalty rewards and early access to new launches.

This entire flow can be written as a recipe.
The CJM engine follows it, deciding when to act, when to wait, and when to stop.

Let’s now try writing it as a recipe

• Discovery Phase
  A customer views a pair of running shoes and adds them to their wishlist.
  Which event should trigger the journey? At what point do you decide this customer is worth engaging?

• Research Phase
  The customer repeatedly views the product, reads reviews, and selects sizes.
  Which signals indicate genuine interest, and what do you define as clear intent?

• Decision Phase
  The shoe’s price drops, or the stock starts running low. This could be the tipping point.
  Which conditions should trigger communication that nudges the customer toward purchase?

• Delight Phase
  After purchase, request a review, offer loyalty rewards, or share care tips.
  What actions help bring the customer back and strengthen their experience with the brand?

Conclusion

Customer journeys are not about sending more messages. They are about making better decisions over time. A map helps you understand what your customer needs, while an engine ensures those decisions are executed with restraint.

When journeys are treated as recipes and tools as instruments, the customer experience stops feeling reactive and starts feeling intentional. The brands that survive won’t be the ones with the most automation, but the ones that know exactly when and when not to act.

At Swym, we don’t use fancy bots to reject you in milliseconds. We’re humans. We’re small, we’re scaling (and we want to stay small keeping exponential growth in mind), and we care more about your drive than your ability to keyword-stuff a resume.

If you’ve been wondering what happens after you hit “Apply,” here is the real story.

🚩 Is Swym Actually For You? (The Vibe Check)

Before we talk about interviews, let’s see if we’re a match. If you’re looking for a long form manual on how to do your job, we are most definitely not the one.

You’ll love it here if:

• You see ambiguity and think “Cool, I get to build the map” rather than “Help, I’m lost”, because you understand that wrapped within the ambiguity is the true size of the opportunity that nobody else can unravel other the ones working on it constantly

• You care about making an impact much more than having a fancy title, because you understand that the voice of impact speaks more consistently, confidently (and louder) than the voice of a title in most rooms if not all, especially in our rooms.

• You know that remote-first doesn’t mean work from under a rock disconnected from reality, because you understand remote-first is a convenience that everyone pays for in bits-and-pieces and more importantly you win by making others win and vice versa and that needs consistent communication that is “persistent” (calls/meetings are not considered communication btw).

• You know that the AI-enabled-you > > > no-AI-you, because you understand that if you don’t take advantage of technology, what you do will eventually become obsolete (in most cases) and you are already eliminating those “grunt” work that bother you from pursuing deeper problems

🛠 The Swym Roadmap: From Hello to Hired

We respect your time. We aim to wrap things up in 2 to 3 weeks. No six month marathons here.

Stage 1 - Questionnaire - All about you

💭What Happens? - A quick screen to see how you think

💡Pro Tip - Be yourself. We can tell when it’s authentic

Stage 2 - Chat with me

💭What Happens? - A vibe check with me (Danica!)

💡Pro Tip - Ask about the culture. I’ll give you the real tea

Stage 3 - Discuss with us

💭What Happens? - Talk shop with a future teammate

💡Pro Tip - This is where you nerd out about the role, everything is on the proverbial table

Stage 4 - Solve/Build with us

💭What Happens? - A practical take-home, real world challenge

💡Pro Tip - Show us your thought process, ask questions/discuss, not just the final answer

Stage 5 - Align with us

💭What Happens? - Align with leads on the vision and how we want to get there

💡Pro Tip - 45 minutes. No trick questions, just real talk

💡 How to Put Your Best Foot Forward

1. Do a Little Homework 📖

If I ask “What do we do?” and you say “I think you guys sell swimsuits?” we’re off to a rocky start. Check our LinkedIn, read our blog (you are already here!), or just browse our site for five minutes (or more hopefully).

2. The STAR Method

When we ask about a time you failed or solved a problem, try the STAR method: Situation, Task, Action, Result. It keeps you from rambling. We’ve all been there!

3. Be a Human

We want to see your brain work. The “ums” and “ahs” are fine. We value a thoughtful conversation over a rehearsed script.

4. Laptop Over Phone 💻

Technical glitches happen, but joining a video interview from a shaky phone while walking your dog makes it hard for us to focus on your story.

🧬 What Makes a “Swymmer”?

We aren’t looking for robots. We look for people who are honest about their values and how they work. We care deeply about:

• Ownership: You aren’t here just to do the thing; you own the outcome.

• Big Impact and High-Agency: You won’t let anything stop you from getting to your outcome, be it your lack of experience or context or know-how, all of those can be acquired when fully aligned. You drive towards the impact, it doesn’t “just happen”.

• Growth Mindset: We win together - You thrive on collaboration and learn from the smart people we have around. Even more important is that you actively raise the bar for the smart folks that we are, making us grow our combined depth/knowledge.

• Customer-First: You always start and end with how this helps the people using what we build, be it an internal customer or an external one.

• Data aware aka “Guessing” with Data: First principle thinking on using data to build your hypotheses - you make decisions based on accessible real info, not all info but the necessary and sufficient info to let you iterate.

• Sustainable Ambition aka Work AND Life: We value hard work but continued hard work is hazardous without healthy boundaries. You know how to define those boundaries responsibly, that prioritizes your life without compromising your or your team’s goals.

• Pure Passion: Whether it’s your craft, a cause, or a personal side project, share it with us. We love seeing what drives your conviction in action.

• AI-enabled: You think and use AI effectively to maximize time spent on deep work. This enables pretty much every other point laid above this, simply impossible to sustain without this first-principle.

❓ Frequently Asked (and Honestly Answered) Questions

Is it remote?

Yes. We are remote-first. We also believe active collaboration is a serious competitive advantage and love working together as well. Our Bangalore space plays the part of an office during those days of intensity. (Cubbon Park is literally a stone’s throw away if the view matters)

Will I get ghosted?

No. We aim to give feedback within 48 hours of each stage. If it isn’t a fit, we will tell you why.

What are you actually looking for?

Ownership, data-informed decisions, and passion. Whether you’re obsessed with scalable systems or great experiences or sourdough baking, we want people who care about something.

What are the responsibilities and deliverables for this role? Where is this role going?

This will sound odd - A lot of the roles that are needed to do justice to our true opportunity have not been defined yet. Knowing that, we don’t always go heavy on the JDs. We instead align on our non-negotiables and your non-negotiables, let the other details evolve with time-bound milestones. Some of our best people have come in as role “X”, shaped up into role “Y” that is carved out based on what the opportunity needed - We love making this happen.

The Bottom Line

We aren’t looking for perfection. We’re looking for your ability to take your potential to its limits and have fun along the way (not just yours, push our collective potential to higher limits). If you want to build things that matter with people who actually like each other, we want to hear from you.

Ready to jump in? Shoot me an email at danica.lobo@swymcorp.com. Let’s build something cool (aka Swym 😊) together.

When most folks were getting ready to buy all your favorite products, at Swym we took this chance to display our ability and engineering excellence at scale.

This was our 10th BFCM at Swym, poised to be the biggest BFCM yet. We onboarded a lot of merchants BFCM’24, but we were also the most prepared this year. We moved all of our services to better infra and improved a lot of our infra practices - we handled 1 Million+ RPM with low turbulence, almost like a breeze, if we daresay.

Here is a quick recap of what we enabled BFCM 2025 for our merchants

More here

This post is the story behind how we engineered this BFCM at Swym.

Let’s divide and conquer the process, we had multiple focus areas that we worked on to make our systems ready for BFCM, we cover them one by one.

Migrating to Kubernetes

Kubernetes was a huge thing in Swym, we were using it for all our queue processors and NodeJS Services, but the bulk of our ecosystem was written in Clojure and they were still on VMs.

During BFCM 2024, we had to provision new VMs and do some capacity planning to make sure we didn’t go down under the BFCM load, but this January this year we realized that we have had enough of this manual provisioning (We used Terraform, but still, it was too slow), so we decided to move our Clojure (pseudo) microservices to Kubernetes as well. (If you are asking Why Clojure? 🤔)

A 2-month long consistent effort was required to onboard all our services to Kubernetes. Every service we onboarded presented its own problems. For example, our Clojure Services presented had some statefulness in them, we had to rewrite the stateful parts of the service to make them stateless. There were also changes in the way configuration was loaded into the services, eg: Clojure services used EDN files for configuration (a Clojure native data notation), which wasn’t the case in NodeJS services.

But in the end after we fixed all the bugs, we saw light at the end of the tunnel, the K8s Migration was complete and our microservices were autoscaling.

We tuned the autoscaler according to our needs and waved a fond Goodbye to the days of manual VM creation and management.

Observability Overhaul (Prometheus, Jaeger, OpenSearch fixes)

When you receive 800-900K requests per minute, you generate 2 to 4 times the amount of logs and traces. We were processing at least 3000 spans per second and about 80-100GB of logs per hour, pre-BFCM. The scale like we anticipated spiked during BFCM.

Logging

Our logging architecture had to improve exponentially to handle this scale. We shifted from logstash to a fluentbit-fluentd based agent-aggregator architecture, for the log collection mechanism.

• Fluentbit pods (agents), running as a part of a daemonset collected the logs from the services and just forwarded (using the fluent forward protocol) them to the Fluentd aggregator. The Agents ran as daemon-sets in their respective nodepools. You can configure a daemonset to run only on a specific set of nodes by setting node affinity.

• The Fluentd aggregator decided which index on OpenSearch to push the logs to, using an custom Lua Script. This helped us ensure that none of the logs were lost

OpenSearch created the indices and maintained them using ISM (Index State Management) policies, which were used to configure log retention and priority, thus keeping storage costs and maintenance manageable.

Tracing

Jaeger is the absolute core of our debugging workflow—losing spans or a Jaeger outage during BFCM would be equivalent to operating blind. Our previous setup wouldn’t cut it, demanding a much more resilient cluster and an upgrade to Jaeger V2.

To future-proof the system, we introduced redundancy:

1. Services push spans to OpenTelemetry (Otel) Collectors.

2. Otel Collectors push the spans into a temporary Kafka buffer (our “Kafka-Span-Buffer”).

3. Otel Kafka Consumers read the spans and write them to OpenSearch.

This Kafka buffer was designed to prevent span loss during temporary downstream issues. However, the sheer write load exposed a major bottleneck: the underlying hard disks (HDDs) reached maximum throughput, causing critical latency spikes.

The Fix: We immediately provisioned a high-performance SSD dedicated exclusively for the primary write index in OpenSearch. After a brief, high-throughput period (e.g., one hour), the index would automatically roll over, and the data stored on the expensive SSDs was migrated to a low-performance archival node. This tactical use of hardware ensured zero write latency during peak traffic periods, while keeping the costs low.

This way we were able to process and save 2.5 billion+ spans during the 4 days of BFCM.

JVM Optimization

Obvious but requisite context - Java compiles to byte code and the byte code runs on the Java Virtual Machine, which in-turn runs on bare metal. This makes Java a versatile and cross-platform programming language. Fun fact, though its heavy, it is faster (comparable to C or C++) when it comes to runtime on a single core CPU. This is because the JVM optimizes your byte code multiple times during runtime. It generates hotpaths for frequently executed code. The JVM can be tuned to give max performance. We missed a very important JVM flag when migrating our services to kubernetes! This caused our services to severely under utilize the available memory.

We had forgotten the MaxRAMPercentage Flag and JVM was defaulting to 25% 🫠 🫠 🫠 !!!

Relearning that from our VM-based deployments quickly, the memory utilization of our VMs became extremely optimal after setting it to 75% and this one flag gave us a lot of perf gains including a significant ART reduction (190-300ms across our services) and a good fistful of dollars saved per hour!

Pro tip - JVM Flags are critical, if someone tells you otherwise, they’re probably C# developers 😉.

I cannot do justice to this finding in such a short paragraph, let me explain the different JVM flags we use and why, in a separate post.

Queue Processor Optimization

A major design choice in our VMs was, the service that was serving API requests was also tasked with processing messages across queues.

The tight coupling of real-time API serving and asynchronous queue processing was a major part of our original VM architecture. While it was manageable at a lower scale, this mixing of responsibilities was inefficient and prevented us from maximizing resource utilization. While separation of concerns sounds like an obvious answer that you would get most engineering minds nodding in agreement, the reality of maintaining more sub-systems for little-to-no-value is something we take seriously. Hence the “why” we need to do it had to go into first principles alignment without throwing the proverbial baby with the bath water.

The Decoupling Strategy

To solve this and fully leverage our Kubernetes migration, we implemented a complete separation of concerns:

1. API Services: Responsible only for handling synchronous, user-facing requests and pushing asynchronous work onto the queue. These services require high availability and predictable performance.

2. Queue Processors: Responsible only for consuming messages from the queue and executing short-lived, asynchronous tasks. These services can tolerate disruption and have variable capacity needs.

Leveraging Azure Spot VMs for Cost Optimization

This separation was key to an immediate and substantial cost optimization.

We achieved this by utilizing Azure Spot Virtual Machines through Azure Kubernetes Service (AKS) Spot Nodepools:

• API Services Deployment: These were deployed onto Reserved Instances (standard, high-availability nodepools) to ensure zero downtime and consistent API performance.

• Queue Processors Deployment: These were moved entirely to Spot Nodepools (using Azure Spot VMs). The disruptable nature of Spot VMs—where Azure can reclaim the resource with a short notice—was entirely acceptable for our queue processors, as the queued messages would simply be picked up by another available Spot VM or, if necessary, a reserved VM once it became available.

Azure Spot Virtual Machines, are basically leftover capacity that Azure wants to use in an effective way. Say Azure has 100 Virtual Machines, and it has rented out 30 to Swym and 20 to CompanyX, now, it has 50 unused VMs. Azure offers these under the Spot Category at fraction of the actual price!! But the caveat is that Azure can reclaim these VMs if it needs them for something else, say, CompanyZ wants 50 VMs. Azure gives a 30 second, eviction notice before reclaiming the capacity.

The above explanation is a very crude one, please read more about Azure Spot VMs here.

The practical implementation was simple: we used an environment flag within our application to toggle between the API-serving logic and the asynchronous processing logic. By running these two configurations on different nodepools, we effectively:

• Improved API Performance: By dedicating highly available resources solely to low-latency API calls.

• Optimized Costs: By running the resource-intensive, interrupt-tolerant asynchronous tasks on highly discounted Spot VMs.

Code Freeze!

There was a strict code freeze during the entire span of the BFCM period, no deployments or config changes were allowed during this period (unless they were bug fixes). To be our own critic - That doesn’t sound like a 2025-ready decision. But we chose to stop deploying any new lines of code without a strong reason that can’t wait for the 5-7 days. This is an area of improvement for 2026, something we keep tinkering on how to enable true CI/CD.

In the meantime, we upgraded our kubernetes clusters, and applied multiple security patches to the existing codebase, further hardening our systems for the impending fun onslaught 😎.

Finally, most of the engineering team (almost all Swymmers are engineers 👩‍💻👨‍💻) got together in Bengaluru and kept an eye aka stared at the BFCM Grafana dashboards for days and nights on a shift basis to celebrate every spike and stat that showed how much of the global ecommerce volumes we helped supporting. Thankfully, there were just murmurings of incidents or outages, lots of (welcome) false flags that drove us to finding better ways of monitoring/concluding if a peak/trough was concerning or not.

Conclusion

True to our core values, we hoped for the best but planned for the worst. And thankfully we surged ahead along with the BFCM rush for our merchants — and our engineering held up to the standards we wanted to set for ourselves 🙌.

The shift to Kubernetes turned capacity spikes into non-events, replacing manual firefighting with automated, cost-efficient elasticity that sailed past 1 million+ RPM (repetitive but we are super thrilled 😄). Our Observability Overhaul paid dividends, processing 2.5 billion+ spans and transforming potential blind spots into clear operational awareness and intelligence across teams.

From relearning like the critical JVM MaxRAMPercentage fix to deploying advanced Spot VM cost-optimizations, every strategic move has helped move our platform forward. Our infrastructure is set for the next phase of our growth. We are scaling, optimizing and ready for whatever the next peak 2026 throws our way.

Here are a few episodes from our podcast on pre-BFCM prep and even an episode in the middle of BFCM 🥵 😎

Every Shopify Editions drops a wave of features, but Winter ’26 feels different. This one wasn’t just about tooling. It was about a shift in how merchants expect to operate and how Shopify expects its ecosystem to evolve.

If you’re building apps on Shopify, this update cycle is a reminder of one thing:
The bar is rising, and the opportunity space is widening at the same time.

A quiet question has started buzzing through developer threads:
“Is this the beginning of apps becoming obsolete?”

Short answer: no.
Long answer: Shopify is expanding the canvas, not closing it. And Winter ’26 proves it.

1. Sidekick Extensibility: The Most Important Developer Update

https://shopify.dev/docs/apps/build/sidekick

If you read only one section of the Editions recap, let it be this.
Sidekick Extensions fundamentally change how merchants interact with apps.

You’re no longer building features that live next to merchant workflows.
You’re building intelligence that lives inside their workflows.

Developers can now:

• Expose app capabilities through natural-language prompts

• Allow merchants to trigger app actions without UI friction

• Inject their logic directly into Sidekick’s conversational interface

• Even construct custom app behaviors through Sidekick itself

Yes, merchants can “build” with Sidekick now. But that doesn’t diminish the role of apps.

If anything, it expands it.

Merchants can prototype ideas with Sidekick.
But when they need scale, reliability, debugging, audits, security, or ongoing evolution, they will turn to apps.

Sidekick becomes the on-ramp, not the substitute.

At Swym, we’re already thinking about what this unlocks.
Imagine a merchant asking Sidekick:

“Show me the top wishlisted items that are back in stock this week and schedule reminders automatically.”

That type of workflow isn’t a UI feature.
It’s conversational commerce infrastructure.
And apps like Wishlist Plus are uniquely positioned to power it.

2. Native A/B Testing: A Signal About Merchant Maturity

Shopify adding first-class A/B testing is not about replacing experimentation apps, it’s about legitimizing behavioral testing as a core operating model.

For developers, this means:

• Standardized schemas for experiment variants

• Cleaner integrations for optimization or personalization apps

• A merchant base newly conditioned to test, measure, and refine

This shift matters.
Apps that interpret test results, automate variant creation, or correlate experiments with user behavior will thrive.

For Swym, this could mean letting merchants:

• Test different wishlist CTA styles

• Understand how nudges perform

• Optimize back-in-stock timing or messaging

The platform giving merchants testing muscle means apps get to offer more sophisticated strategies on top of it.

Added bonus is Simgym, an AI-driven shopper behavior simulator that works like a pre-launch predictive testing environment. Instead of only relying on real traffic and A/B experiments after deployment, SimGym lets merchants run AI shopper simulations based on data from billions of past transactions to estimate how changes might perform.

3. Shopify Network: The Unbundled, Everywhere Shopify

The introduction of Shopify Network makes one thing clear:
Shopify knows the ecosystem now lives far beyond the storefront.

This layer connects shoppers, channels, apps, and stores into a cohesive experience.

For developers, this unlocks:

• More surfaces where your app can provide value

• More events that flow between touchpoints

• More opportunities to be part of a shopper’s journey

Swym has always believed commerce isn’t linear.
A shopper moves between emails, search engines, social feeds, PDPs, and back again.
A wishlist event shouldn’t be siloed, it should fuel the entire network.

Shopify Network validates this philosophy.

4. Global Catalog Moves Center Stage

Global Catalog used to be powerful but peripheral.
Winter ’26 brings it into the center of everything.

It’s now the authoritative source for:

• Global product attributes

• Multi-market pricing

• Translations

• Inventory synchronization

• Multi-store governance

And this aligns beautifully with the new Merchant Hub, built around omnichannel control.

For app developers, the implications are clear:

Think global-first, not store-first.

Apps need to handle:

• Cross-market logic

• Product variants that differ by region

• Attribute-driven automation

• Centralized intelligence

For Swym, this shift is huge. A wishlist isn’t just a “store” feature anymore. It’s a product affinity layer across all markets.

Building on Global Catalog allows wishlist and nudge intelligence to become globally consistent while respecting local rules.

5. Metafield Filtering: Quiet but Transformative

One of the quieter updates, metafield filtering and richer querying, is actually a major win for developers.

You can now:

• Query metafields with more precision

• Filter based on conditions

• Build richer admin experiences

• Reduce API overhead

For any app that depends on merchant-defined product attributes (which is most apps), this is a quality-of-life upgrade.

6. Token Expiry for Offline Access Tokens

A light-touch update but an important one. Offline access tokens now expire, which means apps need to refresh tokens periodically.

This is good security practice.
It doesn’t change how apps fundamentally operate, it simply formalizes a more responsible model.

It’s not something to highlight to merchants; it’s just something developers should quietly adopt.

7. So Are Apps Becoming Obsolete? Absolutely Not.

With Sidekick, Network, Global Catalog, testing, and new admin surfaces, it’s easy to wonder if Shopify is closing in on the space apps occupy.

But the opposite is happening.

Shopify is strengthening the foundation so apps can build the differentiated value.

Every update in Winter ’26 signals that:

• Shopify wants AI-native workflows

• Shopify wants globally consistent product data

• Shopify wants omnichannel-first execution

• Shopify wants more interconnected flows

• Shopify wants apps deeply embedded into merchant operations

This is not a land-grab. It’s a platform uplift.

When Shopify raises the floor, app developers get to raise the ceiling.

And Swym’s perspective here is simple:
These updates don’t reduce the role of apps, they increase the expectations of what great apps should do.

Merchants will expect smarter automation, deeper personalization, and intelligence across surfaces.
Apps that lean into this will shape the next generation of commerce experiences.

8. The Path Forward for App Developers

Here’s what the next era of Shopify apps will be built around:

• Conversational workflows powered by Sidekick

• Global Catalog as the canonical product data layer

• Omnichannel orchestration via Merchant Hub

• Optimization powered by native A/B testing infrastructure

• Network-informed shopper journeys

• Richer, cleaner data access

For Swym, this means doubling down on our core belief:
helping merchants engage shoppers intelligently, across channels, with minimal workflow friction.

The platform is giving us the surfaces, it’s up to apps to bring the intelligence.

Final Thought

Winter ’26 isn’t the story of Shopify replacing apps.
It’s the story of Shopify expanding what apps can be.

For any team building in this ecosystem, this is the moment to lean in, because merchants are about to expect more intelligence, more automation, more omnichannel visibility, and more embedded experiences than ever.

And the apps that embrace this shift will define the next cycle of commerce innovation.

Join me, as I delve into the intricacies of customer experience with Krishnan, the Director of Customer Experience and Support. Discover how Swym bridges the gap between technical expertise and strategic guidance to transform customer interactions into lasting loyalty. This episode explores the critical role of customer experience in driving growth and navigating high-pressure environments. Tune in to learn how Swym’s team turns challenges into opportunities for building trust and delivering exceptional value to merchants.

A Quick Recap of Our Conversation

• Segment 1: The CX Philosophy We started by defining what “CustomerExperience” (CX) truly means. It’s not just “support.” We explored the guiding principles for our team’s very first interaction with a stressed merchant and why that empathetic, strategic approach is different.

• Segment 2: The Everyday Practice We talked about the “how.” Krishnan detailed how we’re structured with Technical Support Engineers (TSEs) and Customer Success Managers (CSMs) to provide a high-touch experience. We also touched on how AI is influencing this practice and the critical importance of hiring for empathy and ownership intent, not just technical skills.

• Segment 3: The Stress Test (BFCM) This is where the engine is truly tested. Krishnan shared the playbook for how we 10x our efficiency (not our staff) for the surge and maintain a human touch under pressure. He also shared a great story from a past BFCM where the team turned a potential disaster into a merchant ‘wow’ moment.

• Segment 4: Advice for Our Partners We finished by turning our lessons into actionable advice. Krishnan pointed out the single biggest mistake we should avoid making in support. Krishnan shared what he wishes every product builder understood about what customers really need.

Some Key Takeaways

• Customer experience is more than just support; it’s about building trust.

• Swym’s team transforms challenges into opportunities for loyalty.

• Technical expertise and strategic guidance are key to customer success.

• Empathy is crucial in customer interactions.

• AI tools help streamline repetitive tasks, allowing focus on important issues.

• Customer feedback is a valuable resource for product improvement.

• Swym’s customer experience team is integral to company growth.

• Effective communication is essential in high-pressure situations.

• Swym’s approach to customer experience involves multiple functions working together.

• Building long-term relationships with customers is a priority.

So, when we got the opportunity to get early access to Shopify’s new Next Gen Developer Platform, we jumped at the chance. We were eager to see what the future of Shopify app development looked like, and we successfully migrated our apps to the new platform even before it was opened up to the entire ecosystem.

We want to give a huge thank you to the team at Shopify for their incredible support. As we navigated the beta migration to the new platform, their help was instrumental. A special shout-out to Nick Wesselman for his guidance, helping to make the transition as smooth as possible.

Now that we’re on the other side, we wanted to share our perspective on the new platform, what we love, the massive wins for developers, and why we believe this is a game-changing leap forward for the entire ecosystem.

The Big Wins: A New Era for App Development

This isn’t just an incremental update; it’s a fundamental re-engineering of the developer experience. Here are the highlights that got our team most excited.

1. Truly Isolated and Parallel Development is Here!

This is, without a doubt, the most significant win for our team. Shopify has completely re-engineered the shopify app dev command, and with it comes a new paradigm for app previews.

To really appreciate the improvement, let’s look at how things used to work. Our development process involved each developer running their own local instance of the app. However, to test changes in a stable, shared environment that mirrored production, we relied on a single “Dev” version of our app in the Shopify Partner Dashboard. This is where the bottleneck appeared.

Imagine Developer A is building a new checkout extension. They’d do their work locally, but to properly test it and get feedback, they would need to push their changes—and update the preview URLs to our central “Dev” app. While they were doing this, that “Dev” app was effectively ‘occupied’. If Developer B finished their work on an admin dashboard widget and also needed to test it in that same stable environment, they had to wait. Pushing their changes would overwrite Developer A’s work-in-progress. This forced us into a queue, where only one developer could safely work in our stable dev environment at a time, significantly slowing down our velocity.

Now, app previews are tied to a specific dev store. This is a massive improvement!

With the new platform, Developer A can connect their local environment to their own dev store, and Developer B can connect to a completely separate dev store. They can both work on their features, see live previews, and test their changes simultaneously, in complete isolation. There’s no more queue and no more risk of overwriting a colleague’s work.

This unlocks true parallel development, allowing our team to move faster and more efficiently.

As a bonus, it eliminates the risk of accidentally updating production URLs 😨 during development, a welcome relief for any engineering lead.

2. From Scripts to Schemas: A New Way to Manage Metafields & Metaobjects

If you’ve ever had to manage metafields or metaobjects across thousands of merchant stores, you know the pain. With the new platform, this nightmare is over. Metafield and metaobject definitions are now declarative, living inside your shopify.app.toml file.

What does this mean in practice? Let’s say you need to add a new metafield. Instead of writing code to create it programmatically on app installation, you simply declare its structure in the TOML file. A simple definition can be just one line. Shopify takes on the responsibility of ensuring this definition is migrated and updated across all merchant stores.

This offloads a huge operational burden from developers to the platform itself. For us, the migration was as simple as removing all our old logic for creating metafields and defining them in the configuration file. The result? Cleaner code, less maintenance, and more time spent building valuable features.

3. App-Scoped Limits: Predictability and Scale

Hallelujah! This is a change that will make every developer’s life easier. Previously, rate limits for resources like metafields and metaobjects were set at the shop level. This meant your app’s ability to function could be impacted by other apps a merchant had installed. If another app consumed most of the store’s metafield limit, your app could fail, leading to confusing support tickets.

Now, every app gets its own set of limits. This provides predictability and ensures that your app has the resources it needs to operate correctly, regardless of what other apps are installed on a store. It’s a change that allows us to build more robust and scalable solutions with confidence.

4. Quality-of-Life Improvements Everywhere

Beyond the major architectural shifts, there are several smaller changes that make a big difference in the day-to-day workflow:

• Improved Partner Dashboard UI: The user interface in the Partner Dashboard has received a noticeable facelift, making it cleaner and more intuitive to navigate.

  

• Targeted Dev Stores: You can now easily create dev stores with specific Shopify plans, like Shopify Plus. This is fantastic for testing plan-specific features without complex workarounds. For apps like ours that offer tailored experiences for Plus merchants, this is an invaluable tool.

• Consistent Extension UUIDs: The hassle of managing extension UUIDs is a thing of the past. Now, an extension’s UUID remains the same across your dev and production app versions. This simplifies configuration management and eliminates the confusion of tracking different IDs across environments.

• Enhanced Webhook Observability: Troubleshooting webhooks is now much simpler. The ability to quickly filter deliveries by status, shop, or topic makes diagnosing and fixing issues significantly faster.

A Minor Hiccup (And a Quick Fix on the Way)

No major platform overhaul is without a few growing pains. One small workflow change we noticed is related to team collaboration on dev stores.

Previously, if a developer on our team created a dev store, anyone else within our Swym Partner organization could easily access it. Now, access is more restricted. The creator of the dev store needs to manually invite other team members as staff members through the store’s settings. It’s a few extra clicks in the process.

The good news? We’ve already shared this feedback with the team at Shopify, and true to form, they were receptive and confirmed they are actively working on a solution. We don’t expect this to be an issue for much longer, which is a testament to Shopify’s commitment to refining the developer experience.

The Verdict: A Huge Leap Forward

Shopify’s Next Gen Developer Platform is more than just an update—it’s a clear signal that Shopify is deeply invested in its developer community. The changes they’ve implemented address long-standing pain points and provide a faster, more robust, and more scalable foundation for building apps.

For us at Swym, this new platform unlocks a higher level of productivity and allows us to focus on what matters most: building incredible tools that help Shopify merchants succeed. We are incredibly excited for the future and can’t wait to see what we can build next!

Perhaps a good time to revisit some of my earliest lessons on the path to scaling Swym for our merchants and partners, hope it helps or just share in the fun we had early on.

It was Nov 9, 2016. We were just about exploding in never before seen daily merchant growth at Swym. It was a day for a SaaS-y unlearning I cherish and look back. Background context I usually don’t spend time talking/writing about, but will be useful to share my learnings - Prior to Swym, I was at CloudPact for a good chunk of time where we built Mowbly (acquired by ASG which was acquired by Rocket Software). Mowbly was an end-to-end cross-platform MADP. The entire team size was sub-10 folks for most of my tenure 😄, stretched to the limits (by choice) that even I have done solo sales prospecting meets, complete with exchanging visiting cards in the traditional sales-y etiquette. Yup, one doesn’t hand it off just like that, which of course I did and for some reason that lead never went anywhere 🤔 - clearly no Dwight Schrute even if I tried.

Coming back to my comfort zone, ie technology - It was a PaaS offering, not a SaaS - build, run, host and manage mobile/cross-platform apps - sorta of an amalgamation on MDM, MAM and RAD tooling with OTA updates. Each customer/enterprise was a full tenant, ie each tenant occupied the whole rental unit, ie separate, not shared infra. There was a cloud offering which was hosted on Google Cloud’s App Engine — For which we also won/featured in few early YourStory Cloud Conclave events back in 2011 and pre-SaaSBoomi ones like iSPIRT). Some enterprises chose the cloud, but most enterprises deployed on their own air-gapped in-house bare metal servers with their DMZs and other fun stuff. Every tenant was managed almost with their own resources and more specifically served by their own dedicated database, compute, etc. We probably had 100s to 1000s of such tenants running. (Fun fact for the unfamiliar - DMZ (Demilitarized Zone) is also the same terminology used to define a buffer zone in areas with military conflicts 😳.)

Now back to Swym — In 2016, we were in the process of building the early pieces of our SaaS stack aimed at enabling merchants give their shoppers great experience across channels. Now we power over 46K brands across the world. But in 2016, we were in the order of early 1000s, a few months before we were in Techstars Seattle class of 2017. Drawing from my past expertise at designing a scalable solution, I went about making certain decisions and one of those that had to be unwound on Nov 9, 2016. We were an extremely tiny team back then, ~5 — some of us were “part-time” but committed full-time 🙇‍♂️. Out of those 5, most were up until ~3:57 am on Nov 8. And for some reason some of those same folks were up again at ~7 am. Clearly not for the faint hearted and clarifying upfront — I wasn’t one of those people.

I’ll try and run through the events, based on our slack messages from that day (and leading) to avoid misremembering notes other than any exchanges via calls.

Nov 8 2016 7:16 am

A merchant pinged us stating that they were getting this error.

502 - Web server received an invalid response while acting as a gateway or proxy server.
There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server.

Context - We had an unrelated DNS outage the previous night, hence the 3:57am messages, but it was resolved. So we let it settle in for a bit longer since the errors were intermittent.

Then we discussed our sync-up plans - even back in 2016 getting all of us in one place at the same time was an accomplishment in itself. Remote FTW!

Things were quiet in terms of errors and whatever alarms we had running for the rest of the day until the night.

Nov 8 2016 10:07 pm

The trend of merchants dropping off was trending upwards - something was fishy. We tried to repro and thankfully found that something is clogging up the service resources very very quickly and leading to the same 502 above.

At that point, our options were to maybe increase the VM size? or maybe add another node? - But, applying a resolution like that was just a mask, we needed to have a reasonable hypothesis.

We dug deeper into each functional step, and fortunately we found out the resource crunch quickly. This wasn’t yet completely clear, we had isolated the erring service and then we began even deeper sifting through resource consumption patterns.

Perhaps the traffic was spiking up? No, no evidence for that, especially not concurrently.

Is it a bot? No, cannot be. But there was a bot running at the same moment. Distracting from the source reason? Perhaps.

Nov 8 2016 10:43 pm (faster typing, words > sentences)

502 again. CPU at 100% - bingo!

Memory leaks? No - CPU.

How about the processes? DB? No, that’s under 22%

No wait, CPU dropped to 0 in all. Fishy...

Okay let’s work on what we know - our logging was excessive, let’s cut that down

The drop-off rates were matching with the CPU charts we were seeing. That’s good-ish.

We were narrowing to the culprit - the db process, building up a hypothesis that supported it. It was blocking everything.

I was against any hypothesis around the database, ie functions/feature problems, looking for any other alternative theory than the db. Why — That meant there were fundamental design mistakes made, ie I made bad choices. So, I wanted to be super certain there could be no other reason.

At that point, we switched from English words to just direct Clojure on Slack comms.

(if existing_site? (go to dashboard) (continue here with setup))

Along with the above modification, we upgraded the node capacity and reduced logging — let’s see 🤞

Nov 8 2016 11:50 pm

What routes were suspect? Which method or webhook?. We landed on a couple.

At the same time — 74% CPU on the upgraded nodes.

This was going to be a long night. (nevertheless we were prepped to bring our best 🙌)

Nov 8 2016 11:54 pm

Should I upload the new code?

Your call.

*Gulps* (not visible on slack :P)

Amidst all that, one of us connected to the dev instance and proclaimed “wait a min...”. But no lucky breaks that night.

Nov 9 2016 12:06 am

mysqld is taking more than 100% CPU

There it was, plain and simple.

A lot of queries with “Waiting for table level lock”

At this stage, we jumped on a quick call to decide if we fight now or patch and punt it for later. We applied a couple of patches and decided to call it an official downtime to give space to analyze further.

We shut shop for new merchants pretty much. It was a gutting feel 😞

We needed a break and distance from the problem, so quite a few unsure moments till sunrise

Nov 9 2016 9:31 am

Our rockstar dev (Who is this you wonder? Not me for sure. IYKYK 😄) had figured out the methods/routes for the overload and she was adding more diagnostics.

We wanted to upgrade MySQL connection types to InnoDB, but come on, table level locks still can’t be a thing in 2016, no? All relevant indexes were added for the major queries as part of our first deployment - “what is going on” feel.

Over the sync up call, we argued — well it was mostly me arguing why it wasn’t a problem even though it most definitely was the problem. It was a challenging call for all of us. We had no new merchants at a time when we were just starting to gain momentum.

The crux of our problem - When we implemented that system, I had insisted on a design to generate new table namespaces for each new merchant we had - clearly that made sense to me based on how I had seen systems scale (ie CloudPact/Mowbly context from earlier). This was the blunder that caused the downtime pretty much - loading more table definitions per merchant we acquired at our scale was disastrous. The scale was tens of thousands, not 100s/1000s that I was thinking of earlier.

The above realization and conclusion came about as I was cycling my usual 5K to work (i.e. our 4-seater space at NASSCOM 10K Startup Warehouse at Diamond District). It was clear — I had to unlearn that path of scale. The cost and value are very very different than what I was familiar with. Something I didn’t need to be told, I had to adapt to the problem at hand, not a great feeling but the correct one to put myself through. The cycling to office was part of the process as well.

Nov 9 2016 10:11 am

When I stepped in to restart the discussion, we were all in agreement somehow, even though I had argued for the opposite just 30 mins ago.

That was another moment I have come to cherish — despite how wrong I was and the heated debate, all of us moved on to what was important - getting us back LIVE. Super grateful to be surrounded by such folks, both at Swym and CloudPact before that. (gifs for representation only)

Getting back to next steps - we quickly concluded on a clear 7-step plan including the table namespace changes, logging changes, archival of spam namespaces and deployment. 7-steps = 1 step per hour at least, no? 😁

Nov 9 2016 3:37 pm

Pushing to prod now

Any objections?

Nope

All done, CPU at <5%

Alright, alright, alright - We were back. A lesson unlearnt, a new lesson learnt, a lesson implemented.

It was time to get back on the mountain of other things that we were ignoring 🏃‍♂️.

Last slack message for Nov 9 2016 was 9:29 pm. But then again on Nov 10 the first channel message was 3:52 am - back at it ⏲️

Now back to 2025, we have completely eliminated the above system including the self-hosted MySQL instance in question. That system was running our Shopify integration and extensions connecting back to our platform. We have moved all of that to a unified design taking advantage of the latest Shopify extensibility and toml-based deployments including the new dev dashboard + cli.

Speaking of November, here is the latest from our team to enable you to maximize the rest of 2025 with the holiday season imminent

May the force be with all of us this BFCM 🙌✌️

I’m joined by an incredible lineup of guests:

👩‍💻 Trudy & Anne – the brilliant duo behind Design Packs

🛍️ Prakhar – co-founder of FoxSell and a super active Shopify community contributor

💡 Aravind – VP of Engineering at Swym

✨ Developer Experience: How these founders got started on Shopify, their favorite tools, and the biggest challenges in building for the platform

🤝 App Collaborations: Behind-the-scenes of successful app partnerships, including Wishlist Plus, and lessons learned

🌍 Community in Action: How the Shopify community supports each other, from Slack tips to long-term collaborations

🤖 Future of Shopify Development: Exploring AI’s impact on coding, design, and merchant support

📚 Advice for New Developers: Practical tips to get started and thrive in the Shopify ecosystem

💡 Plus, hear fun stories, insights from leadership and dev perspectives, and a glimpse into the future of building on Shopify!

If you’re a developer, founder, or just curious about Shopify’s ecosystem and community, this episode is packed with inspiration and actionable insights.

Sounds familiar?

The problem isn't that AI is broken. The problem is you're directing it like you're taking a blurry vacation selfie….when you should be guiding it like you're filming an Oscar-winning movie

Let me try to fix that for you

Shorter Prompts = Better Results

This breaks everyone's brain, but it's true: Long prompts make AI dumber (because of reasoning).

Think of reasoning AI like a goldfish. The more information you dump on it, the more it forgets (neglects) what you actually wanted.

Bad prompt (87 words):

"I need you to write a comprehensive, detailed, and thorough email that professionally communicates to my team about the upcoming quarterly review meeting, making sure to include all the relevant details about timing, preparation requirements, agenda items, and expectations while maintaining a friendly but professional tone that encourages participation."

Good prompt (12 words):

"Write a team email about quarterly review meeting. Include timing, agenda, prep."

Result? The short prompt consistently produces better emails.

Token Counter Link

Show, Don't Tell (The Magic of One Example)

Here's something that sounds fake but isn't: One good example beats ten mediocre ones.

It's like teaching someone to make a perfect omelet. You don't show them 10 different omelet techniques. You show them ONE perfect omelet.

Without example:

Prompt: "Write product bullet points"

AI Output:

"• Great product features

• Amazing quality

• Best in class"

(Useless generic garbage)

With ONE example:

Prompt:

"Write product bullet points like this example:

• Noise cancellation blocks 99% of background chatter (perfect for open offices)

Now write 3 more for wireless headphones:"

AI Output:

"• 40-hour battery life means charging once per week, not daily

• Touch controls respond to taps, not accidental brushes

• Folds flat to fit in laptop bags under 2 inch thick"

(Actually useful!)

AI Isn’t like Google (It works differently)

Reality check: By default, AI doesn’t “look things up.” It predicts answers based on patterns….which means it can invent details with total confidence.

With tools: Sure, AI can pull in the latest stock prices, sports results, or web data. But even then, its real strength isn’t retrieving facts….it’s helping you interpret them.

Smart approach:

❌ “What’s the Apple stock price right now?”
✅ “Here’s Apple stock data [paste or fetch with a tool]. What trends or risks do you see?”

Be Stupidly Specific

Vague prompts are like asking someone to "make dinner." Cool…enjoy your bowl of cereal now…🙂

Vague prompt:

"Write a report about our sales"

AI thinks:

Report could mean anything. Sales from when? How long? What format? Screw it, I'll just write whatever.

Specific prompt:

"Write a 300-word sales summary for October 2024. Include total revenue, top 3 products, and biggest challenge. Use bullet points."

AI thinks:

Oh, now I know exactly what to do.

The "Spartan" Hack

Want responses without fluff? Use this one weird word: "Spartan"

Seriously….It's like a magic spell that makes AI cut the BS...

Normal prompt:

"Explain why our website is slow"

AI gives you:

A 300-word essay about server optimization, CDNs etc…

Spartan prompt:

"Explain why our website is slow. Be Spartan."

AI gives you:

Too many plugins. Large images not compressed. Hosting plan is basic...

Test Your Prompts Like a Scientist

A prompt that works once is like a lottery ticket that has won once. Meaningless.

The 10-Test Rule:

• Run your prompt 10 times

• Count how many outputs you'd actually use

• If less than 7/10 are good, refine and repeat

The 5-Part Prompt Formula

Every great prompt follows this recipe:

1. Context (Set the scene)

2. Task (What to do)

3. Format (How to deliver it)

4. Rules (Constraints)

5. Example (Show don't tell)

Bad prompt:

"Write about our company"

Good prompt using the formula:

Context: You're writing for busy executives who have 30 seconds to understand what we do.

Task: Write a company description.
Format: 2 sentences max.

Rules: No jargon, no buzzwords.

Example: "Slack helps teams communicate without email. Over 10 million people use it daily."

Conclusion

These days companies winning with AI aren't the ones with the biggest budgets or fanciest tools; they’re the ones that know how to talk to AI like a sharp intern who just needs clear instructions. So let’s start optimizing our prompts from the drafting phase itself

Thats all for today, I've got more AI stuff brewing….will comeback with few soon….Bye bye 🫡

But stick around, because this story has a happy ending - a 3.2-second ending, to be precise! It involves a large table, a seemingly obvious query, a facepalm moment, and a crucial reminder about the fundamentals we sometimes overlook. Whether you're just dipping your toes into databases or you're a seasoned pro, I bet you'll find something useful (or at least relatable) here.

The Mission: Counting Unique User Devices

My task seemed simple enough: In our event_logs table (a beast with over 312 MILLION rows, consuming about 43 GB of disk space!), I needed to find the total number of unique combinations of session_key and user_tag for one specific account_id.

Easy peasy, right? My brain immediately went: "Unique? That's a job for DISTINCT!" So, I proudly typed out something like this:

SQL

-- My "Logical" First Attempt
SELECT
    COUNT(DISTINCT (session_key, user_tag)) -- Count unique pairs, right?
FROM
    event_logs
WHERE
    account_id = 'some_specific_account_id';

Looks reasonable, doesn't it? We filter by the account, then ask Postgres to count the distinct pairs of session_key and user_tag. Job done?

The Reality Check: 43 Seconds of Waiting...

I hit 'Run' and... waited. And waited.

(Imagine a clock ticking loudly here... maybe a tumbleweed rolling past)

43.3 seconds later, I got my number. Okay, getting the result is good, but over 40 seconds for a count? On a production system, that could feel like an eternity for users or downstream processes. Something wasn't right. The massive table size was obviously a factor, but could it be this slow?

The Investigation: Do We Have Backup? (Checking Indexes!)

Alright, Query Optimization 101: If a query filtering on a column (account_id in my case) is slow on a huge table, the first suspect is usually a missing index. So, I went digging.

Aha! We did have indexes:

1. event_logs_account_id_event_time_idx on (account_id, event_time) - Okay, helpful for the WHERE clause, but doesn't help with the session_key or user_tag part.

2. event_logs_pkey on (account_id, session_key, user_tag) - Wait a minute... Primary Key? Unique index? On all three columns involved?

(Lightbulb flickering on)

The Eureka Moment: The Primary Key's Superpower!

This is where my dusty college notes suddenly felt relevant! Specifically, that Primary Key guarantee is a direct example of the 'C' for Consistency in ACID properties - ensuring the database state always respects the defined rules and constraints.

A Primary Key (or any Unique Index) guarantees that the combination of values in its columns is unique across the entire table.

Our primary key is on (account_id, session_key, user_tag).

Let's think about this:

• We are filtering for one specific account_id.

• For every row matching that account_id, the combination of (account_id, session_key, user_tag) must be unique.

• If the account_id part is the same for all these rows... what does that mean for the remaining (session_key, user_tag) part?

It means (session_key, user_tag) must also be unique within that filtered set!

If we had two rows for the same account with the same session_key and user_tag, it would violate the primary key!

My COUNT(DISTINCT (session_key, user_tag)) was completely redundant! I was asking the database to do a whole lot of extra work to find uniqueness that was already guaranteed by the table structure itself!

The Fix: Embrace Simplicity!

Realizing this, the fix was laughably simple. If every row for that account already represents a unique (session_key, user_tag) pair, I don't need to find the distinct pairs... I just need to count the total number of rows for that account!

SQL

-- The Gloriously Simple & FAST Query
SELECT
    COUNT(*) -- Just count all the rows matching the account!
FROM
    event_logs
WHERE
    account_id = 'some_specific_account_id';

The Result: Blazing Speed! (3.2 Seconds!)

I ran this new query, holding my breath... and BOOM!
3.2 seconds.

From 43.3 seconds to 3.2 seconds. That's nearly 13 times faster! All by removing one seemingly innocent DISTINCT.

The Science Bit: Why is DISTINCT So Demanding?

So, why was DISTINCT slowing things down so much? Is it evil?

Not at all! But it is hard work for the database. To find unique rows/values, Postgres usually has to:

1. Gather all the matching rows (potentially millions in my case, even after filtering by account_id).

2. Either Sort all that data based on the distinct columns and then pick out the unique ones.

3. Or Hash each row/value into a temporary table in memory, checking for duplicates as it goes.

Both sorting and hashing huge amounts of data take significant CPU time and memory. If it needs more memory than allocated (work_mem setting in Postgres), it starts using the disk, and performance plummets dramatically.

In my first query, the database was likely doing a massive sort or hash operation on all the (session_key, user_tag) pairs for that account only to arrive at the same number, COUNT(*) would have given instantly (well, almost instantly!). We were saved because the primary key let us skip that whole expensive process.

The Takeaway: Know Your Constraints!

This whole adventure was a powerful reminder:

1. Understand Your Data & Schema: Constraints like Primary Keys and Unique Indexes aren't just for data integrity; they provide valuable information the query planner can use (and that you can use to write smarter queries!).

2. Question Your Assumptions: The "obvious" query isn't always the best. DISTINCT seemed logical, but the context of the unique index made it unnecessary.

3. Indexes are Your Friends: While the primary key was the hero here, proper indexing is fundamental for database performance, especially on large tables.

4. DISTINCT is Powerful but Costly: Use it when you need it, but be aware of its performance implications and double-check if it's truly necessary.

So, next time your query feels sluggish, take a moment to revisit your table structure, your indexes, and your constraints. You might find, a simple key (pun intended!) unlocks massive performance gains.

Have you had similar "Eureka!" moments optimizing queries? Share your stories in the comments below - let's learn from each other!

Happy querying!

"Aha!" thinks my brain, "Async! That's a job for future!"

It felt so right, so Clojure-y. Just wrap the call in
(future (super-cruncher args)) and boom! Instant background task, right? My main thread is free, latency stays low, everyone's happy.

Then came the plot twist.

This super-cruncher function? It's popular. Like, really popular. We're potentially talking 50,000 requests per second needing to call this thing. Suddenly, my simple, elegant future started looking... less simple.

My Spidey-sense tingled. Could just throwing 50,000 future calls a second into the ether actually work without, you know, causing a digital apocalypse in production? Time for a quick huddle with the collective wisdom (and some helpful LLMs).

And here's the mind-blown moment I had, which might be new to you too:

future isn't magic pixie dust; it's a Thread-Summoning Spell!

Okay, maybe not a spell, but here's the crucial bit: Every time you call future, Clojure dips into its shared, fixed-size agent thread pool and grabs a thread to run your code.

"Shared?" you ask. Yes! "Fixed-size?" Double yes!

Think of it like a popular coffee shop with a limited number of baristas (threads). If one or two people order complex drinks (long-running tasks wrapped in future), it's fine. The other baristas keep the line moving.

But what happens at 50,000 RPS?

Imagine 50,000 customers per second slamming the counter, each demanding a dedicated barista right now. That cozy coffee shop? It becomes chaos!

1. Thread Pool Exhaustion: That "fixed-size" pool runs out of available threads FAST. New future calls have to wait, potentially blocking other things that might rely on that same shared pool (like agents!). Latency, the very thing I wanted to avoid, could skyrocket.

2. Memory Mania: Every thread needs memory for its stack and other resources. Spinning up potentially thousands (or tens of thousands!) of threads, even if short-lived, puts a strain on memory.

3. Context-Switching Calamity: The CPU (or JVM) has to constantly switch between active threads. With a huge number of threads, it spends more time managing the threads than actually doing the work inside them. It's like our baristas spending all their time bumping into each other instead of making coffee. Performance tanks.

Whoa. My simple future plan suddenly looked like paving a highway to Production Hell with good intentions. At 50,000 RPS, relying on future and its shared pool is like trying to drink from a firehose – you're gonna get overwhelmed.

Is future bad? Absolutely not!

It's fantastic for:

• One-off background tasks.

• CPU-bound work you want off the main thread occasionally.

• Things that don't happen at insane frequencies.

But for hyper-frequent, high-throughput async calls like my super-cruncher scenario? It's likely the wrong tool for the job. Using it there risks performance degradation, increased latency, and potential system instability under sustained load.

My Big Takeaway:

Know your tools! future is wonderfully simple, but understanding how it works (shared thread pool!) is critical before deploying it into the high-frequency async battlefield. For scenarios like mine, exploring alternatives like core.async, dedicated thread pools managed more carefully, message queues, or potentially non-blocking patterns might be necessary.

So, next time you reach for future, give a little nod to that shared thread pool. Ask yourself: "How busy is this highway going to be?" It might just save you from an unexpected thread tsunami!

Happy (and mindful) coding!

Recently, that changed. Faced with the same request involving nearly 600,000 Save for Later actions, it was a deal breaker for the customer. Instead of saying no, we said, "Let's try something." In just a few hours, without pulling in a single developer from our product team, we had a robust, working import solution. How? By pairing up with Gemini.

This wasn't just about getting a task done; it proved that a new way of working is possible.

The Challenge: A Multi-Step Data Puzzle

The goal sounded simple. Take a customer's CSV file and import their users' Save for Later items into our system. But the details were complex:

1. The customer's file had the user's email and the Shopify Product ID, but it was missing the Variant ID, which is crucial for our APIs.

2. The dataset was huge—600,000 actions spread across 10,000 unique products.

3. The import itself required a precise, four-step API dance for every single user: generate a session, check for an existing list, create one if needed, and finally, add the items.

Doing this manually was impossible, and building a one-off tool would traditionally be a significant development project.

The Journey: Building It, One Step at a Time

Here’s how we tackled it, piece by piece, with the AI acting as a patient, expert developer.

Phase 1: Enriching the Data with Shopify’s API

Our first hurdle was fetching the missing variant_id for the 10,000 unique products.

Gemini immediately pointed us to Shopify's Bulk Operation API—the right tool for any large-scale data job. It wrote a Python script to handle the process, but this is where the real collaboration began. We didn't just get a script; we learned as we went. We hit errors, and Gemini helped us debug them.

• A KeyError taught us about API permissions and how to create a custom Shopify app with the right "scopes."

• A 400 Bad Request error taught us about missing parameters in an API call.

• A TypeError when we scaled up to thousands of products taught us about API query length limits and led us to the solution: batch processing.

With each step, the script became more robust, finally evolving into a powerful tool that could reliably fetch data for all 10,000 products in minutes.

Phase 2: Assembling the Final File

With our new "lookup table" of variant IDs, we needed to merge it back into the main 600,000-row file. Gemini suggested using the pandas library and provided a clean, efficient script to perform the merge, ensuring the row order was preserved for our final import.

Phase 3: The Final Import

This was the most complex part. We had to orchestrate the four API calls for what could be tens of thousands of unique users. Gemini helped us structure the logic to be incredibly efficient:

1. Group by User: Instead of 600,000 loops, the script intelligently grouped the data by email, processing each user only once.

2. Conditional Logic: It seamlessly handled the "if-then" logic: if a user has a list, use it; if not, create one.

3. Robust Logging: For a process that would run for hours, we knew we couldn't just watch the terminal. Gemini built a detailed logging system, creating a progress summary and a separate file for any failed items, making the entire process transparent and manageable.

Bridging the Gap: From Local Script to Production Environment

The final challenge wasn't about code. It was about the practicality of the script running. A script that needs to run for over days can't live on a personal laptop. It needed a home on a stable, production-grade server—in our case, the Azure node.

As a non-developer, accessing this kind of environment felt like a major roadblock. This is where another crucial partnership came into play—this time with our DevOps team.

We explained the goal and the tool we had built. With their help, what seemed like a complex technical barrier became a simple, straightforward step. They provided access and guidance with minimal effort, empowering us to take our solution to the finish line. It proved that when a clear business need is met with cross-team collaboration, technical hurdles disappear.

The Realization: It's More Than Just Writing Code

The "magic" wasn't just that an AI could write Python scripts. It was the collaborative process. It was the speed of iteration. A bug that might have taken hours to diagnose was solved in seconds.

This journey proved two things:

1. We are more capable than we think. Tasks that once seemed out of reach for non-developers are now achievable. We can be more responsive to customer needs without immediately burdening our engineering team.

2. This is a new partnership. Working with an AI isn't about replacing our skills; it's about augmenting them. It’s like having a senior developer available 24/7 to help you think through a problem, write the boilerplate, and spot the mistakes.

The result? We turned a request that would have been rejected into a success story. And more importantly, we’ve unlocked a new, faster, and more creative way to solve problems for our customers.

Jumping into action immediately.

A Systematic Approach to Problem-Solving

The initial investigation quickly confirmed that a JavaScript error was the culprit, preventing product details from rendering correctly when a variant was changed. The specific error was an Uncaught TypeError, indicating that the code was trying to read a value that didn't exist.

Uncaught TypeError: Cannot read properties of null (reading 'amount')

In situations like this, speed and accuracy are paramount. While I could have manually traced the code line-by-line, our commitment to efficient resolution means leveraging the best tools for the job. To accelerate the process, we framed the problem for an AI assistant to act as a diagnostic co-pilot.

AI as an Efficiency Co-Pilot, Not the Pilot

I provided the relevant code snippet to AI to rapidly test our hypothesis. This allowed me to bypass a lengthy manual search and instantly pinpoint the source of the issue.

The analysis confirmed the suspicion: the code was accessing a product's compareAtPrice field without first checking if the product was actually on sale. If a product variant didn't have a "compare at" price, the value was null, causing the script to fail.

The problematic line was a simple conditional check:

if(item.node.variants.edges[0].node.compareAtPrice.amount > item.node.variants.edges[0].node.price.amount) {

It explained that I was trying to access .amount from compareAtPrice without first checking if compareAtPrice even existed. If a product wasn't on sale, that object would be null, and the code would crash.

Next, it became my guide. A good theory needs proof. It didn't just tell me what was wrong; it gave me the exact ways to confirm it. It suggested I add a series of console.log statements to act as a trail of breadcrumbs, letting me watch the data as it flowed through the script.

const firstVariant = item.node.variants.edges[0]?.node; console.log("Debugging Product Variants:", item.node.variants.edges); console.log("First Variant:", firstVariant); console.log("compareAtPrice:", firstVariant?.compareAtPrice); console.log("compareAtPrice.amount:", firstVariant?.compareAtPrice?.amount); console.log("price:", firstVariant?.price?.amount);

I dropped the logs in and re-ran the code.

Then came the "Aha!" moment. The console lit up, and the evidence was undeniable. Staring right back at me was the proof:

Debugging Product Variants: (5) [{…}, {…}, {…}, {…}, {…}] First Variant: {id: 'gid://shopify/ProductVariant/321', title: 'abc', sku: '123', availableForSale: false, quantityAvailable: 0, …} compareAtPrice: null compareAtPrice.amount: undefined price: 109.99

We had our culprit. The theory was correct. The hunt was over.

Finally, it provided the elegant solution. It immediately recommended a safe way to access the property: assign it a default value of “0“ when passed null, and proceed to the IF condition only then.

The existing IF condition was replaced by the below:

const firstVariant = item.node.variants.edges[0]?.node; const compareAtPrice = firstVariant?.compareAtPrice?.amount ?? 0; // Set default to 0 if null const price = firstVariant?.price?.amount ?? 0; if (compareAtPrice > price) {

The Outcome: Support That Just Works

The result? From diagnosis to the entire fix was completed in under five minutes.

The Wishlist button now works flawlessly, ensuring their customers enjoy the seamless shopping experience they expect.

This incident is a perfect example of our support philosophy. AI isn't a replacement for expertise; it's a powerful enabler. By using AI as a co-pilot, we empower our skilled team to achieve business goals faster. It allows us to accelerate debugging, pinpoint issues with incredible speed, and deliver the fast, effective support that helps our clients succeed.

Imagine a team of ambitious engineers hired to build a skyscraper in record time. Their focus?

• 🚀 “Let’s go taller — add 30 more floors!”

• ⚡ “Install high-speed elevators that reach the top in seconds!”

• 💼 “Let’s make space for 10,000 people to work inside!”

From the outside, it looks like innovation and progress. But here’s what they missed:

🧱 The foundation is barely reinforced.
It wasn’t designed to handle even half the load they’re now pushing.

So, what happens?

• Hairline cracks appear in the walls.

• Some floors begin to tilt under uneven stress.

• Elevators start jamming because the building is shifting.

Despite the cutting-edge materials, smart design of the top floors, and fast construction — the entire structure becomes dangerous.

🧩 Software Analogy: Scaling Infrastructure Without Schema

Now, switch to software.

The equivalent of "building more floors" is:

• Adding more services (e.g. microservices).

• Deploying Kubernetes clusters.

• Adding more engineers to “scale up fast.”

• Expanding APIs, data pipelines, or regions.

But underneath it all, they never defined a strong schema — a structured, validated data model that all services agree on.

🔥 The cracks in this software skyscraper:

• Silent overwrites: One service changes price for a flash sale; another for a discount — one wins, one loses, no visibility.

• Schema drift: JSON blobs evolve differently in different services — nobody knows what the data really looks like anymore.

• Debugging chaos: “Where did this null come from? Who updated this field? Why is this product live in Canada with no inventory?”

✅ Real Scalability Begins with Schema + Reason

To avoid this, systems need a schema-first and reason-aware architecture.

🔹 Step 1: Define a Strong, Structured Schema

Use schema validation tools like:

• 🟪 Malli for Clojure

• 🔵 Zod for TypeScript

• 🟨 Avro for data pipelines

(def Product
  [:map
   [:id string?]
   [:price [:map
            [:value number?]
            [:source [:enum :manual :promo :flash-sale]]]]
   [:title [:map
            [:value string?]
            [:source [:enum :default :seo :localization]]]]
   [:vendor string?]])

📌 Benefits:

• You know who made the change

• You can enforce source-specific rules

• You prevent silent overwrites

🔹 Step 2: Isolate Updates by Reason

Now, each update must carry context — a reason code or intent.

{
  "reason": "seo-title-optimization",
  "updates": {
    "title": {
      "value": "Top 10 Snowboards for 2025",
      "source": "seo"
    }
  }
}

✅ With this structure, you can now:

• Allow only certain fields to be updated per reason

• Reject updates that don’t align with purpose

🧠 Think of this like:

No one’s allowed to enter a room without stating why they’re there.

🔹 Step 3: Versioning and Validation

Schemas evolve. Build with versioning from day one.

(def ProductV2
  [:merge Product
   [:map
    [:inventory [:map
                 [:available boolean?]
                 [:quantity pos-int?]]]]])

Your system can now:

• Enforce rules by schema version

• Handle backward-compatible fallbacks

• Alert teams when consumers use outdated formats

❌ Why Infra Isn’t the Fix

Scaling infrastructure doesn’t solve these fundamental modeling failures:

• Race conditions due to overlapping updates

• Misleading dashboards and metrics

• Bugs in prod that no one can trace back

🧱 Infra scales operations. But if your foundation is broken, it just scales the chaos.

⚡️ Speed Is a Feature — But So Is Stability

As a startup, there’s relentless pressure to move fast:

• Ship the MVP.

• Prove traction.

• Get user feedback.

• Iterate rapidly.

In this race, it’s easy — and often encouraged — to skip the architectural “nice-to-haves” like schema design, validation layers, traceability, or contract enforcement between services. After all:

“We’ll fix it when it breaks.”
“We need speed now; structure can come later.”

And in the early days, this approach seems to work:

• Features get shipped in days.

• APIs evolve freely.

• Bugs are fixed quickly by the people who built them.

But here's the hidden cost:

You're accumulating invisible structural debt.

🧱 The Building Blocks You're Skipping

What gets skipped?

• ✅ Schema design: No contract for what data should look like.

• ✅ Ownership boundaries: No clarity on which service owns what field.

• ✅ Reason for change: No traceability for why a field was updated.

• ✅ Validation rules: Inconsistent assumptions across services.

• ✅ Versioning: Every consumer assumes they understand the shape of the data.

These are not gold-plating. These are the load-bearing walls of your future system.

🚨 What Happens When You Scale

As usage increases, or your team grows:

1. Engineers run into each other:

   • “Why did my service break after your deployment?”

   • “Who changed this product title? I can't tell from logs.”

2. Customers see broken behavior:

   • Flash sales priced incorrectly.

   • Products unavailable but still visible.

3. Your team gets slower:

   • Every new engineer has to reverse-engineer what the system expects.

   • Debugging takes hours because there’s no audit trail.

   • New features introduce regressions in unpredictable places.

You started fast — but now you're spending that speed as interest on your foundation debt.

🩹 Patching Over Cracks Doesn’t Work

When this happens, many startups reach for quick patches:

• More tests.

• More rules in code.

• More monitoring.

But if the foundation is inconsistent — if your data can’t be trusted — then these patches only paper over systemic instability.

Imagine trying to reinforce a skyscraper with duct tape. That’s what patching feels like without revisiting your core data model.

✅ The Balanced Approach: Build Fast, Revisit Foundations

You don’t need to design the perfect system on day one. But you do need to:

• 🌱 Start with minimal, clear schemas — even if lightweight.

• 🧠 Capture the reason behind each change early.

• 🧭 Make traceability a first-class concern.

• 🔄 Revisit and refine your building blocks regularly.

Treat it like a gardener’s mindset, not an architect’s fantasy:

• Build fast, but prune and structure as you go.

• Let your data grow, but don’t let it grow wild.

🏁 Final Word

⚠️ Moving fast on a broken foundation feels like speed — until it turns into chaos.

If you're serious about scalability, customer experience, and developer velocity, then schema design, ownership clarity, and structured evolution are not optional. It is one of the important core blocks of building scalable software.

They're the rails that let your train go fast without derailing.