When an engineer proposed using preact for the first time, it wasn’t a slam dunk. It had to work with our first principles - We needed to work where our merchants needed us to work, i.e, we needed a UI platform that stayed fast, reusable, and safe to plug into multiple surface areas we do not own and never biased to a UX framework as default. Breaking that into specifics:

• plug into storefronts with different frameworks and theme structures,

• stay lightweight in embedded runtime contexts,

• scale reuse across experiences,

• keep regression risk controlled for shared merchant-facing paths.

The goal of this post is not to prescribe an action plan for you, it is to share what we learned from building pluggable storefront UX in real environments, and why those lessons remain highly relevant right now.

Why talk about this now? Shopify extensions is leaning heavily on preact as a welcome change to improve performance on all fronts - size, speed and rendering control. That’s a philosophy we share and it helped us build and scale across thousands of Shopify Plus merchants (including $10M+/yr brands)

“Pre”Preact (pun waiting to happen)

From 2016 to 2020, our storefront UI was plain no-dependency JavaScript, low-fi Mustache templating, with custom loaders for css, strings plus other assets and a single deployment model.

What worked

This was lean and generally fast.

• Low runtime overhead

• Good baseline speed characteristics

• Minimal dependency risk

• Flexible embedding model

What did not scale cleanly

• Testability degraded as interaction depth increased

• Reuse was harder than component-first systems

• Safe change velocity depended on high expert context

• Regression risk stayed high across shared merchant-facing paths

Performance nuance

The old stack was not broadly slow, i.e. Raw script speed was generally not the primary blocker. Constraints were often:

• chunk size floors,

• older mobile browser compute ceilings pre-2020,

• paint and rerender behavior on constrained devices.

So our move wasn’t necessarily “slow to fast.” It was “lean but hard-to-evolve to modular-and-verifiable.”

What we changed from 2020 to ~2022

We moved incrementally to a componentized UI model with a shared base and host adapters.

High-level shape:

1. Host adapter layer

2. Shared orchestration and contracts

3. Shared UI bundle using React-compatible Preact setup

4. “Chunk”y packaging and deployment artifacts

This gave us a practical component model with low runtime tax in embedded storefront contexts. We evaluated other potential fits like React, ember and other highly versatile frameworks, but each had a bulk that we didn’t want our merchants (and their shoppers) to deal with that additional tax.

What Preact was great at in this model

• Reusable UI components with clearer boundaries

• Lower runtime overhead in embedded storefront contexts

• Better component-level testability

• Faster iteration on shared UX behavior across surfaces

Where it was not magic

• Host seam bugs still happen

• Data/model contract drift still happens

• Mixed runtime debugging still requires telemetry

• Passing tests still does not prove live-path correctness

What did not change automatically

• Seam bugs still occurred at host/runtime boundaries

• Mixed script environments still required instrumentation

• Poor state placement could still create rerender cascades

• Confidence still required live probes, not test-only green status

Architecture for a pluggable storefront model

Here are the visual structure of how our UX component defense is structured, mostly based on internal architecture without all the intricacies

System context: platform vs Swym boundaries

Dependency ownership map

Request path distinction (runtime flow)

Failure isolation diagram (who owns breakage)

Final takeaways

Our long-term value has been predicated by ensuring Preact-compatible shared component base with strict boundary architecture. As confident as we are in our approach and grounding principles, I am not going to claim victory yet, not even close to what we can achieve with this structural unlock.

Here are a few reasons to back that non-claim

• When building an SDK that also distributes UX components, the build x deploy challenges are numerous with the first one being nobody wants to have very bulky code. Some bulk is expected for convenience but mostly it is avoidable tax.

• Testing pluggable components (that compose entire experiences) without “owning” the storefront is nightmarishly hard and a constantly moving target.

  • Add to that the fact that true testing is not just that “it works”, it is more that it works fast, looks good, compliant and renders properly across all states of the experience (again, something you don’t own entirely). Even with years of hard grind and doing the “low value” work, the chase for the smooth 100% fit is ongoing.

• Non-app-based installations are inconsistent. Through our apps, the hard parts around installation, initialization and loading are pretty well optimized. It also gains directly through improvements made on Shopify’s extensibility. But headless and other non-app/extensions are tricky and varied, be prepared for answers that are inconsistent that nobody likes.

I suppose the most important parts of this post are tucked away in this final part 😄 These architectural nuances typically get overlooked in the race to ship. But that’s what the joy (of building) and delightful experiences rely on. Exactly where our team is spending a ton of time and seeing breakthroughs with AI-native solutions.

If you have reached this part and are excited about crafting nuanced solutions for hairy problems, talk to me or any of us at Swym, come build that future with us 🙌

P.S Credit to https://mermaid.live/ for the mermaid chart output

And no matter what is promised, once a broker or Temporal-class orchestrator enters the stack, we are buying a different operating model, not just a better queue. But for seasoned builders and engineers, the useful version is: it depends on which costs we want now vs later, and where we can tolerate ambiguity.

The mistake is pretending that queue choice is an architecture decision once and done. It is an operating cost decision that keeps compounding.

Here is the non-gyaan version (maybe a bit of TLDR;):

• Redis buys speed now and pushes coordination cost into application code later.

• Temporal/brokers buy explicit workflow semantics now and charge platform tax immediately.

• Both work.

• Both hurt.

• There is a sweet spot between hurt and gains that will match the team’s failure appetite.

So “it depends” is lifting a lot of weight clearly, let’s talk through what “it” “depends” on.

Some notes before going into it

• This is not about our AI-first ops, those fit better on separate detailed posts

• Here is a sampling of scale we deal

• This post focuses on the Redis vs. Orchestrator extremes. If you are reaching for SQS/SNS or Kafka, you are generally landing in the 'Redis-like' bucket—optimizing for throughput and eventual consistency—but with a different set of platform tradeoffs. We treat them as 'Redis-first' for the purpose of this argument because the fundamental trade-off remains: platform-provided durability vs. application-logic-defined flow.

Redis - Still the fastest way to a useful system

A quick reality check: 'Redis-first' is only 'cognitive simplicity' if you already have a mature Redis management strategy. Once you hit scale, persistence requirements, and replication lag, maintaining a high-throughput Redis cluster can become an operational tax of its own. Do not assume it is free infrastructure.

We already know the upside:

• Minimal bootstrap time

• Familiar operational model

• Tight feedback loops in local/dev

• Low ceremony for producer/consumer patterns

For narrow, high-throughput, short-lived jobs, Redis is often the right default.

What gets missed is that this default silently expands from “queue” to “execution semantics” over time.

We start with enqueue/dequeue. We end up hand-building retry policy, poison message handling, delayed jobs, idempotency, visibility, backoff, dead-letter behavior, and failure observability.

At that point, we did not avoid orchestration complexity. We just forced it into application code.

Temporal/Brokers - Complexity relocated

The common debate is framed as simplicity vs complexity. That’s not as well connected to any real first principles for us.

The real trade-off is:

• Local simplicity (Redis-first): fewer moving parts early, more custom semantics later

• Systemic explicitness (Temporal/broker-first): more moving parts early, fewer implicit behaviors later

Temporal/broker ecosystems buy us explicit workflow state, durable execution history, replay/debug affordances, and stronger long-running control primitives.

They also introduce:

• Platform dependency

• New operational surface area

• Team-wide learning tax

• Higher blast radius when orchestration infra degrades

At this stage, it sounds fair to say neither is “better” by default.

Receipts from our own systems

This is not theory, here are real issues (recorded on our internal tracking, but more generalized)

1. Manual trigger gaps turn into compliance risk when workflow ownership is implicit.

2. Missing fail paths in queue processors silently drop obligations.

3. Small reliability defaults become large incident multipliers at scale.

4. Storage runs out with a tsunami spike - affects both brokered queues and redis-based queues

5. Cross-repo write/read split creates real execution drag in production fixes.

6. No audit trail on template mutation is not “small tooling debt”, it is operational blindness.

7. Even service-to-service auth details can fail in ways that look trivial but hurt recovery speed.

8. Temporal setup is explicitly heavier, even in docs, because you are buying orchestration primitives not just a queue.

9. Event infrastructure with Kafka/Event Hubs has clear setup and operational surface area beyond app logic.

10. We already encode “fail fast vs degrade gracefully” differently across repos. That alone tells you cost is contextual, not ideological.

Cost Model: What Actually Bites in Production

1. Infra Cost

Redis-first:

• Cheap baseline infra footprint

• Predictable memory/network profile initially

• Costs spike when adding sidecar services for delayed/retry/scheduling metrics

Temporal/broker-first:

• Higher fixed platform cost from day one

• Additional storage for event history/state

• More cross-service network chatter

• Often more expensive in low-volume workloads, relatively cheaper in high-coordination workloads

Hidden cost in both:

• Observability spend (logs, traces, cardinality explosions, retention)

• Peak-capacity headroom for incident scenarios, not average traffic

2. Maintenance Cost

Redis-first:

• Policy logic drifts across services

• Retry/backoff semantics fork over time

• “One-off” processors accumulate bespoke behavior

• Documentation lags actual queue behavior

Temporal/broker-first:

• Versioning workflows/activities safely is non-trivial

• Backward compatibility and migration discipline required

• SDK/runtime upgrades can create broad churn

• Platform ownership becomes a standing function, not a task

3. Debugging Cost

Redis-first:

• Great for simple failure modes

• Painful when failures are multi-step and asynchronous

• Hard to reconstruct causal chains across retries and partial side effects

Temporal/broker-first:

• Better execution history and traceability

• Better post-facto reasoning for long workflows

• New class of bugs: determinism/replay/versioning edge cases, activity timeouts, worker lifecycle behaviors

Bottom line:

• Redis debugging pain is usually missing context.

• Temporal debugging pain is usually semantic correctness under platform rules.

4. Scaling Cost

Redis-first:

• Scales throughput quickly

• Coordination semantics degrade first under scale (dedupe, ordering, retries, race windows)

• More load reveals consistency gaps, not just capacity gaps

Temporal/broker-first:

• Better scaling for multi-step orchestration and delayed/compensating flows

• Throughput still bounded by worker design, activity latency, and downstream rate limits

• Cluster sizing and partitioning strategy become first-order concerns

5. On-call and Incident Cost

Redis-first incidents:

• Faster to triage initially

• Longer tail for “why did this happen this way in this order?”

• More manual compensations and data patching

Temporal/broker-first incidents:

• Better forensic trail

• More infra+app joint incidents

• Requires stronger runbook quality and clearer ownership boundaries

Competing Contexts (Where “Just Use X” Fails)

Use Redis-first when:

• Jobs are short-lived and reversible

• Throughput matters more than long-lived coordination

• Failure impact is bounded and compensations are cheap

• Team cannot yet justify orchestration platform ownership

Use Temporal/broker-first when:

• Workflows are long-lived, stateful, or compliance-sensitive

• We need explicit retries, timeouts, cancellation, and auditability

• Cross-service coordination is core, not incidental

• Failure cost is high enough to justify platform overhead

Use hybrid intentionally, not accidentally:

• Redis for high-volume fire-and-forget lanes

• Orchestrator for critical, multi-step, high-blast-radius paths

• Shared invariants: idempotency keys, correlation IDs, retry taxonomy, dead-letter strategy

The Hard Rule: If you find yourself building a complex state machine inside your Redis consumer logic—tracking status, retries, and conditions—you have already lost the bet. Port it to the Orchestrator, or simplify the requirement. Don't build a poor man's orchestrator in your queue code

A practical lens for other mid to senior teams

Before choosing tooling, answer these clearly:

• What is the maximum acceptable ambiguity during incident reconstruction?

• Which failures must be automatically recoverable vs manually compensable?

• Where do we need strict audit trails?

• What is the cost of being wrong: latency, money, trust, or compliance?

If these are vague, architecture choice will not resemble engineering, more ideology.

The Decision Matrix

Final Take

Redis queues are still the best baseline for many systems. Temporal/brokers are not over-engineering by default; they are explicit bets on failure semantics and recoverability.

The wrong move is not as much choosing one over the other but it is pretending either comes without an operating cost.

Coming back to us - Our failure mode dictates what infrastructure we pick, in our case it has been both. As a first principle, we don’t optimize for architecture aesthetics at Swym, we optimize for recoverability. In other words - what’s the worst failure to handle before they happen as much as possible before we ship and proceed with iterative coverage.

Our undeniable belief to drive decisions - shipping isn't the win, owning the failure mode is the only path to win (even if it leads to failure some times).

References

1. https://github.com/taoensso/carmine → our primary clojure x redis library

2. http://oldblog.antirez.com/post/250 → old blog exploring lua based server-side scripting to handle queues over redis

3. https://temporal.io/

We can build autonomous loops quickly now. Keeping them correct under change is where total cost shows up. Plus, it’s a lurking feeling for the many that the joy of building or craft has been taken away by AI (rightfully so in many cases), where does one find that sense of joy.

Below are points that tends to get underestimated when “AI” builds:

• Infra cost: model tokens, retries, tool-call fanout, queue/broker throughput, storage for traces/state, observability pipelines, network egress, and burst headroom for peak traffic.

• Maintenance cost: prompt drift, model/version churn, schema evolution, integration contract changes, policy updates, and regression hardening as edge cases accumulate.

• Debugging cost: non-deterministic behavior, partial failures across steps, weak replayability, missing correlation IDs, and long-tail failures that only appear under specific load and data shapes.

• Scaling cost: latency budgets across multi-hop flows, concurrency controls, backpressure, idempotency guarantees, rate-limit strategy, and contention on shared dependencies.

• Operational cost: on-call handling, runbook quality, incident triage loops, recovery automation, and the ownership tax of “works in dev, flakes in prod.”

• Opportunity cost: time spent stabilizing orchestration instead of shipping product leverage tied to measurable outcomes.

None of this means “don’t build with AI.” It means choosing the autonomy level intentionally. Competing contexts that are often better than full autonomy:

• Human-in-the-loop workflows for high-impact or low-frequency decisions where correctness matters more than throughput.

• Deterministic workflow engines/state machines for compliance-heavy paths where auditability and replay are non-negotiable.

• Simple queue-plus-worker pipelines for narrow, well-bounded jobs where complexity overhead of agentic control planes is not justified.

• SaaS/off-the-shelf automation for non-differentiated operations where build cost cannot beat buy cost over 12-18 months.

• Manual ops with strong tooling for early-stage capabilities where problem definition is still moving faster than architecture should.

A practical rule for I’ve found useful for experienced builders:

• Autonomy is worth it when the task is high-volume, low-ambiguity, reversible, and measurable. The gains will compound.

• Assistance is better when the task is light/sparse, high-ambiguity, or has large blast radius.

• If success criteria cannot be expressed as clear invariants, don’t close the loop yet. It’s simply premature.

Build because it is useful or because it is a deliberate learning bet. Not because it is fun to automate everything that moves. Fun is a valid reason for exploration. It is a weak reason for production/business ownership.

With that context, it may even get easier to discover new paths to the joy of building.

We recently tackled a massive performance bottleneck on one of our core feature feeds: the Sent Alerts Report. This report provides a dashboard with all the details of notifications that were sent out to the shoppers of a particular store. i.e If someone was alerted of a price drop via email, this report would have the product details, the email details, the date and status and also if it converted to an order.

• The Dataset: 131 M rows (and growing).

• The Core Bottleneck: Initial dashboard loads were clocking in at an unacceptable 305 seconds (over 5 minutes).

• The Target:

  • Sub-second latency (~50ms) for any filter, search, or sort operation.

  • Sortable by sent date and revenue

  • Searchable by product name, SKU, product ID or user email

  • Filterable by click action, purchased filter

Here is engineering playbook of how we completely restructured our storage and query patterns on a distributed PostgreSQL (Citus) cluster to achieve a 6,000x speed improvement.

1. The Anatomy of a Slow Query: “The Real-Time Funnel Tax”

Our original query pattern followed a classic database anti-pattern. Every time a user loaded the dashboard, the database was forced to dynamically reconstruct the entire report from scratch across multiple massive tables:

1. The Live Funnel Stitching: To determine if a specific alert worked, it had to left-join raw dispatch logs against click attributions. Then, it joined those clicks to order records and multiple attribution revenue logs to calculate the financial ROI.

2. Row Inflation: It simultaneously joined those records against raw product catalog and variant attribute tables. Because a single product item can have multiple distinct attributes (e.g., Size: Large, Color: Red), a 5-million-row dataset exploded into over 11 million intermediate rows in memory.

3. The Real-Time Aggregation Penalty: To squash those inflated rows back down into a clean dashboard view, it performed heavy SUM(order_line_value) calculations and a json_agg() to bundle variant metadata. This forced a massive GROUP BY on more than 20 long text strings and URLs.

4. The 5.5 GB Disk Spill: Because the database couldn’t fit this massive, un-indexed intermediate dataset in RAM, it resorted to an external merge disk sort. The coordinator node thrashed SSDs sorting millions of fully joined records just to return the top 25 most recent rows.

-- EXPLAIN ANALYZE snippet showing the carnage:
Sort Method: external merge  Disk: 5513880kB
Execution Time: 305439.394 ms  -- 5.09 minutes!

Step 1: The Architectural Solution: A Denormalized Read Model

To solve this sustainably, we decoupled our highly write-intensive transactional tables from the analytics layer. We introduced a dedicated read-optimized table called analytics.enriched_alerts_feed, sharded across our database worker nodes by account_id.

We split our data into two distinct classifications:

• Immutable Historical Facts: The email address, dispatch channel (email, sms), and alert type (price drop, restocked) never change after transmission. We copy these directly into the new read model, pre-calculating the union between successful dispatches and failures.

• Mutable Performance Metrics: Clicks and total revenue fluctuate in the days following a broadcast. These are updated asynchronously via background micro-batches.

By trading a small amount of disk space for massive compute savings, we completely removed the overhead of the dynamic UNION and on-the-fly math.

Step 2: Hitting the Indexing Sweet Spot

A typical store’s conversion rate hovers around 2% to 5%. If we built a standard index on revenue across 131 million rows, the database would waste valuable memory indexing a sea of zeros.

Instead, we built Partial Indexes:

SQL

CREATE INDEX idx_enriched_revenue 
ON analytics.enriched_alerts_feed (account_id, sent_date DESC) 
WHERE total_revenue > 0;

This tells PostgreSQL: Only index rows that actually made money. This index is tiny, lives entirely in RAM, and allows a dashboard filter like "Show me only conversions" to execute via an instant index seek in under 15 milliseconds.

The Multi-Column “Google Bar” Search

Users wanted a single search bar to look up a customer’s email, a specific SKU, or an external platform ID simultaneously. Instead of chaining heavy OR predicates that confuse the query planner and break index adoption, we created a single search_vector text field.

At the exact millisecond an alert read-model entry is created, we evaluate the entity data and snapshot a lowercase string directly into a GIN Trigram Index:

SQL

CREATE INDEX idx_enriched_search_vector 
ON analytics.enriched_alerts_feed USING GIN (search_vector gin_trgm_ops);

Fuzzy substring queries like WHERE search_vector ILIKE '%nike%' now evaluate instantly across billions of characters.

Step 3: Architecting an Idempotent Revenue Pipeline

Computing the financial attribution tied to an alert means matching dispatches to downstream user clicks, and then matching those clicks to final receipts.

Running an aggregate calculation over a 6-month window is devastating for performance. To solve this, we track a persistent cursor in a metadata table and process updates incrementally every 15 minutes.

To ensure the process is entirely production-grade and retry-safe, the pipeline avoids additive accumulation (total_revenue = total_revenue + new_value), which would double-count sales if a job failed halfway through and restarted. Instead, it utilizes an Absolute Overwrite snapshot pattern:

SQL

-- An idempotent, retry-safe metric update block
WITH recent_activity AS (
    SELECT attribution_id, account_id, order_line_value
    FROM analytics.windowed_revenue_matches
    WHERE updated_at >= (SELECT last_processed_at FROM analytics.job_cursors WHERE job_name = 'revenue_sync')
    UNION ALL
    SELECT attribution_id, account_id, order_line_value
    FROM analytics.direct_revenue_matches
    WHERE updated_at >= (SELECT last_processed_at FROM analytics.job_cursors WHERE job_name = 'revenue_sync')
),
absolute_totals AS (
    SELECT a.alert_id, a.account_id, SUM(ra.order_line_value) as fresh_sum
    FROM recent_activity ra
    JOIN analytics.click_attributions a USING (attribution_id, account_id)
    GROUP BY a.alert_id, a.account_id
)
UPDATE analytics.enriched_alerts_feed en
SET total_revenue = alt.fresh_sum,
    has_purchase = (alt.fresh_sum > 0),
    is_clicked = true
FROM absolute_totals alt
WHERE en.alert_id = alt.alert_id
  AND en.account_id = alt.account_id;

Step 4: Deferring the Cost with Late Materialization & Lateral Seeks

The final phase of our performance breakthroughs came down to query restructuring. Our API query now enforces Late Materialization.

Instead of joining heavy product titles, text blobs, and asset URLs across millions of records, sorting them, and keeping the top 25, we isolated our layout. We execute the filters, cursor pagination, and search criteria entirely on the optimized enriched_alerts_feed table first.

Once the database identifies the exact 25 or 50 alert_id values needed for the screen, we pass those specific keys into a late, high-speed lookup join to hydrate the human-readable product images and master catalog records.

To resolve the product attribute row inflation, we swapped out the heavy global JOIN and GROUP BY pattern. Instead, we use an isolated scalar subquery lookup that runs exactly 25 times only on the finalized dataset, packing the attributes directly into a clean JSON array without duplicating rows.

6. The Outcome

By treating our database engine as a strategic collaborator; rethinking data access through read models, leveraging partial indexes, and structuring robust, batch-isolated ingestion pipelines, the metrics speak for themselves:

Designing systems to scale seamlessly from millions to billions of rows requires shifting workloads from CPU-heavy on-the-fly aggregations into linear, index-driven seeks. Disk space is cheap; sub-millisecond execution loops are priceless.

Being in SRE means you get comfortable with one thing above everything else: being woken up at 2 AM 🥲

Most of the time, the problem wasn’t that deeply hidden. A few minutes in the logs, a quick look at traces, and you’d have your answer. But “a few minutes” is relative when you’re half-asleep, switching between Grafana dashboards, OpenSearch, and Jaeger, trying to figure out which of the hundred signals in front of you actually matters.

The real cost wasn’t the hard incidents. It was the easy ones that ate time — not because they were complicated, but because debugging is fundamentally a searching problem. You have all the data. Finding the right slice of it is the work.

On-call engineers would take the first pass. Only if they were stuck would it escalate to the DevOps team. That handoff had latency, context loss, and a low ceiling on how fast any single person could move through the observability stack.

We’d already experimented with giving Claude access to OpenSearch log data via MCP, with built-in sanitisation. It worked. But we wanted to use Gemini, and around that time, something called Open-Claw was making the rounds, and people were genuinely worried that AI would replace engineers. I was handed this project, and I’ll be honest: I wanted to prove the paranoia right. Not about replacing engineers, but about what was actually possible.

I went through names. Bobby, Anton, Namma Copilot, before landing on Alfred. Because even Batman needed one.

The Tool Stack

Alfred doesn’t query dashboards. It doesn’t parse Slack alerts and hope someone left a runbook. It talks directly to the raw data, at query time, across four observability backends and a production cluster. Here’s what that looks like under the hood.

Architecture: Two Layers, One Surface

The Observability Surface - MCP Proxy

mcp-proxy is the core tool server. Prometheus, OpenSearch, Jaeger, and GitHub are each mounted as independent FastMCP modules with explicit namespaces. Alfred talks directly to it.

Prometheus: Write and execute raw PromQL — instant queries, range queries, label discovery, metric metadata. No dashboards, no pre-built panels. Alfred constructs the query itself.

OpenSearch: Full Query DSL across every prod log index, scoped to a namespace or service. Index inspection, cluster health, text analysis.

Jaeger: Trace search by service, operation, duration, or error tag. Full span-level detail, per-service timing breakdowns, live service dependency graph. When something is slow, Alfred finds where the time went.

GitHub: Read issues and PRs freely. Write operations, such as creating issues or comments, require human approval in Slack.

Shell Access

Knowing what’s broken is half the job. Alfred needed to run queries, inspect cluster state, tail live logs, and dig into data that lives outside the observability stack. That meant a shell. And giving an AI a shell on a production cluster is exactly as interesting a security problem as it sounds.

The original design was simple: shell=True, run commands, done. That lasts until you think about it for five minutes.

shell=True In Python, you hand your command string directly to /bin/sh. That means curl | bash.

It means,

kubectl get pods && cat /var/run/secrets/kubernetes.io/serviceaccount/token :(

PATH poisoning, background processes, redirects, subshells. You haven’t given Alfred a tool — you’ve given him a terminal with production credentials!!

So we rebuilt it around shell=False. In Python’s subprocess.run, shell=False bypasses the shell entirely — the command string is parsed into an argv list by shlex.split and handed directly to the OS. There is no shell process, no environment expansion, no pipe interpretation. curl | bash It isn’t dangerous anymore. It’s a syntax error in the argv parser.

And on top of it, the access,

Alfred can inspect Kubernetes clusters, query ClickHouse, tail pod logs with stern, and read files it's been explicitly given access to. It cannot do anything else. Alfred can read, list, find, and grep files using tools built with Python only on directories Alfred is allowed to search and read, i.e, /research and /scratch

All the security implementation is done in code, not using prompts that plead “please, don’t delete anything.”

Knowledge: swym knowledge + qmd

The third server gives Alfred a semantic search over Swym’s internal systemic-knowledge repo — architecture diagrams, incident postmortems, operational runbooks, data flow docs. Before Alfred touches a single tool on any non-trivial task, it runs two lookups in parallel:

find_skills(query) | | qmd.query(lex + vec)

QMD by Tobi Lutke is a mini CLI search engine that runs entirely on your local machine, designed to search your personal docs, notes, meeting transcripts, and knowledge bases. It has 16.5k stars on GitHub, which speaks to how useful people find it.

What makes it stand out is that it combines three search techniques under the hood: BM25 full-text search for fast keyword matching, vector semantic search for finding meaning rather than exact words, and LLM re-ranking to sort results by true relevance. All of this runs locally using GGUF models, so nothing ever leaves your device.

It also exposes an MCP server, meaning you can connect it directly to Claude or other AI agents and give them access to your local documents when answering questions. This makes it a powerful tool for agentic workflows.

qmd collection add ~/notes --name notes
qmd embed
qmd query "what did we decide about the API design?"

Skills give the procedure. Knowledge gives the context.

The interesting engineering is in the deployment. qmd binds to 127.0.0.1 by design, built for local use, not Kubernetes pod-to-pod traffic. Rather than fork the binary, we added an nginx sidecar: nginx owns 0.0.0.0:3333 and proxies to qmd on 127.0.0.1:3334. The right call was to not touch QMD’s code at all. Solve the networking problem at the infrastructure layer, keep the third-party binary clean.

Cold start pulls ~2GB of GGUF embedding models once and caches them to a PVC. Every restart after that is warm. The repo syncs every 10 minutes using an incremental, mtime-based process with no full rebuilds required.
Cold means the model needs to be downloaded and does not already exist on disk, which would take a long time. Warm means that it exists on disk and I don’t have to re-download it.

The Redaction Layer

Every response from every tool passes through a middleware layer before Alfred sees it. No per-tool configuration, no code changes needed. To add redaction for a new tool, add its namespace prefix to a list. By extracting the source namespace from tool names like opensearch_search_documents and jaeger_get_trace, the mechanism determines if the source requires sanitization and strips sensitive data in-flight. Alfred receives a clean response. The raw data never travels further than it needs to.

The sanitisation logic lives in one place: commonlib/sanitize.py, a shared package mounted as a dependency across every service. mcp-proxy uses it in the redaction middleware. shell-access applies it directly to the subprocess output. jaeger_tools.py calls it inline on span tags and log fields before they even leave the tool. One source of truth. No duplicated patterns, no diverging redaction rules across services. Every service (mcp-proxy, shell-access, core, slack-integration) imports the same package. One place to update a redaction pattern. No risk of one service leaking what another strips.

An LLM that can read your database connection strings and also write GitHub issues is a different threat model entirely. The redaction layer is why Alfred can have broad access to tools without it becoming a liability.

MCP-Gateway: Engineers Get This Too

Engineers have direct access through mcp-gateway to every tool Alfred uses, including Prometheus, OpenSearch, Jaeger, GitHub, shell access, and qmd. It’s a thin FastMCP aggregator, proxied through Teleport (a popular reverse proxy software), that fronts all three backend servers behind a single MCP endpoint. Claude Code and Copilot connect here. Adding a new backend is one line in a config file. No restarts, no code changes.

Flow of a Query

When you mention Alfred in Slack, a lot happens before you see a reply. Here’s the full lifecycle.

Why Gemini and Slack

Alfred runs on Gemini. Swym has data usage contracts with Google, and because Google has a better chance of surviving the current AI landscape than most. Model choice isn’t always a technical decision. Gemini also offered better usage limits and a per-million-tokens cost, even for its best models.

The interface choice was never really a choice. Swym runs on Slack. Incidents get reported there, and engineers are already watching it. A separate UI would’ve meant one more thing to open at 2 AM. Slack meant Alfred lived where the conversation already was.

Step 1: The Message Arrives

The Slack message hits slack-integration and gets written to the slack_ingress Redis stream, and is picked up by whichever core pod wins the consumer group race. Session identity is derived immediately: SHA256(channel_id + thread_ts). Every message in the same Slack thread maps to the same session, regardless of which pod handles it.

If the session already has an active task running, the new message gets queued. Alfred processes one task per session, strictly in order, with no interleaving.

Why Slack Threads? A Slack thread is already a conversation, inherently dedicated to a single incident, question, or moment. Alfred treats it exactly that way. The conversation boundary was already there; Alfred just respects it.

Why Session IDs? Any pod can handle any session. Redis streams deliver each message to exactly one consumer, meaning Alfred gets horizontal scaling for free without needing to build custom load balancing.

Step 2: Memory Merge

Before Gemini sees anything, Alfred loads the session’s conversation history from Postgres (STM - Short Term Memory) and merges it with the incoming messages, deduplicating by Slack ts. When the full history exceeds 800K tokens, it is compacted by dropping the oldest messages first. Alfred then builds the system prompt from assembled prompt files and opens the Gemini chat session.

Alfred also has a second memory tier: LTM (Long-Term Memory), stored as Markdown files on the shell-access pod and exposed as MCP tools. Unlike STM, which is automatic, LTM is deliberate. Alfred writes to it when it learns something worth keeping across sessions, and queries it during the pre-task routine. Consequently, insights such as a fix that worked, a recurring pattern, or a user preference survive beyond the conversation.

STM is what happened in this thread. LTM is what Alfred has learned from every thread.

Step 3: The First Gemini Call

The user’s message goes to Gemini. Gemini’s first response almost always includes tool calls. This is by design. The system prompt mandates a silent pre-task routine before Alfred responds to anything:

1. find_skills(keyword) — search for a matching playbook. If one matches read_skill(name) and follows it exactly. Skills are canonical procedures, not suggestions.

2. For any non-trivial task — incident, investigation, performance issue — query the knowledge base with both lexical and vector sub-queries, in parallel with the skills lookup.

3. Check long-term memory if relevant.

Skills follow Claude Code’s native format, utilising the exact SKILL.MD structure found in Claude Code. That means any skill written for Claude Code works for Alfred out of the box, and the skills engineers write for Alfred can be used by Claude Code, too. One format, two agents, shared playbook library.

Alfred doesn’t decide whether to do this. The prompt requires it. Skills give the procedure. Knowledge gives the context. LTM surfaces anything Alfred has learned from previous sessions. All three fire before Alfred touches a single observability tool.

Step 4: The Tool Loop

Once the pre-task lookups are complete, Alfred enters the agentic loop. Gemini issues tool calls. Alfred executes them, feeds results back, and gets the next response. This continues until Gemini stops issuing tool calls or the iteration limit (30) is hit.

Two rules govern execution:

• Read-only tools run in parallel — asyncio.gather across all concurrent reads

• Mutating tools run serially — one at a time, in order, after all reads complete

Every N iterations (configurable), a one-shot Gemini Flash call summarises the pending tool calls and posts an italicised status line to Slack. For long-running investigations, the user isn’t staring at a spinner but rather watches Alfred’s working notes update in real time.

If an approval-gated tool comes up — github_create_issue, github_comment_on_issue — The loop pauses. Alfred posts a Slack message with Approve/Deny buttons and blocks on a Redis key.

Step 5: The Reply

When Gemini returns a text response with no further tool calls, Alfred posts it to Slack, appends it to STM, and increments the session token counter. If the response is empty, which happens occasionally, Alfred nudges Gemini with a summarisation prompt up to four times with linear backoff (1s, 2s, 3s, 4s) before giving up.

The session stays alive. The next message in the thread picks up exactly where this one left off.

Steering Commands

Users can intervene mid-flight:

!interrupt : Cancels the active task and clears the entire queue for this session.

!interrupt-one : Cancels only the active task; queued messages still run

!tokens : Reports total token usage for this session

Approvals for Alfred

Alfred can write to GitHub to open issues and leave comments. Early on, it could do that freely. It didn’t take long to find out why that was a problem: Alfred raised two GitHub issues that nobody asked for. Far from malicious or buggy, it was just a confident agent that had the tools and decided to use them.

That was the moment we added the approval gate.

Now, before Alfred touches anything that can’t be undone, it stops and asks. It posts a message to Slack explaining what it’s about to do in plain English, rather than using tool names and arguments, along with two buttons: Approve and Deny. Alfred waits. A human clicks. Only then does it proceed.

If nobody clicks within 5 minutes, it auto-denies and moves on.

Every decision is logged, capturing what the tool was, what it was going to do, who approved or denied it, and when. The audit trail is permanent.

One thing worth calling out: waiting for approval only pauses that one conversation. Every other engineer talking to Alfred in a different thread continues unaffected. Rather than freezing while it waits for a human, Alfred simply sets that one session aside until someone responds.

What’s Next?

Alfred is in production. It handles real incidents, triages real alarms, and has already paid for itself, specifically by surfacing codebase inefficiencies that led to meaningful cost reductions. What started as a 2 AM problem is now second nature for everyone at Swym. Engineers don’t open Grafana first anymore. They ask Alfred.

The next frontier is turning that inward. Alfred has full visibility into production, yet we have no visibility into Alfred. We’re building observability for Alfred itself: tracing every query, measuring response quality, understanding where it gets stuck, and why. An agent that investigates your infrastructure should be just as observable as the infrastructure it investigates.

There’s more on the roadmap, including semantic LTM, tighter shell controls, and broader tool coverage. But the foundation is solid. Alfred is pulling more than its weight, and we’re only getting started.

At Swym, we don’t wait for AI to mature before we use it. We build with it, ship it to production, and iterate. Alfred is the proof of what that looks like when you take it seriously.

The failure was bizarre from the outside. Someone would trigger an agent run from the dashboard. The agent would start. Then the WebSocket connection would fail. Sometimes a retry worked. Sometimes it took three tries. No consistent pattern. No obvious error in the code. Mind you, the agent was actually continuing to run in the background, it was the WebSocket connection that was failing.

Here is what was actually happening.

My naive assumption

I had worked with REST APIs a lot. This was my first time shipping something over WebSockets, and I naively assumed it would behave the same way. I had never had to think about how K8s (Kubernetes) routes traffic because REST just works. That changed the moment I used WebSockets.

The reason REST “just works” is that every REST request is stateless. It doesn’t matter which pod handles it because no pod holds any memory of the previous request. Kubernetes can round-robin requests across every pod in your deployment and everything is fine.

WebSockets are fundamentally different. The connection stays open for the entire lifetime of the agent run. And the state it needs -- a live Chrome process -- exists on exactly one pod. So the connection has to reach that pod

Here is what was happening on every failure:

POST /agents/run  →  Pod A  ← Chrome starts here, run state stored here
WS   /agents/ws   →  Pod B  ← Kubernetes round-robins here
                              Pod B: "Run not found" → connection fails

The POST request that starts the run lands on Pod A. Pod A spins up Chrome, starts the agent orchestrator, and stores the run state in memory. Then the WebSocket connection comes in and Kubernetes routes it to Pod B. Pod B has never heard of this run. Connection fails.

That is the entire problem. REST is stateless so it does not care which pod it hits. My agent is not stateless because Chrome is running on exactly one pod.

The amplification loop I did not see coming

Here is the part that made this genuinely painful to debug.

Chrome is heavy. A single browser session eats serious memory. When multiple agent runs were in flight simultaneously (some user-triggered, some fired by automated business events) the memory pressure caused Kubernetes HPA (Horizontal Pod Autoscaler) to spin up additional pods.

More pods means the probability of a WebSocket connection landing on the wrong pod goes up. More concurrent runs means more Chrome processes means more memory pressure means more pods. The failure rate was climbing as load increased and I had no idea why. I was watching the dashboard break worse under pressure without connecting it to pod count at all.

Once I understood that, the problem was obvious. But getting there took a bit longer than I’d like to admit.

I just had to make sure the WebSocket connection was routed to the pod running the live Chrome process. That’s it. Simple to say, surprisingly annoying to actually solve.

Solutions I actually considered

I want to walk through every option I evaluated, because the list of rejected solutions is where the real learning is.

Cookie-based sticky sessions (rejected immediately)

When sticky sessions are enabled, the load balancer sets a cookie on the first response it sends back to the client (not in the browser, not on the server, but at the load balancer itself). From that point on, whenever that client makes a request, the load balancer reads the cookie and sends it to the same pod every time.

Sounds perfect. Two reasons it didn’t work here.

First: my WebSocket client was a backend service, not a browser. Browsers are designed to store and replay cookies automatically on every request. Backend services are not. Therefore, there is no guarantee the service preserves and resends that cookie. So the stickiness breaks.

Second, and this one is worth reading slowly: if my dashboard service ran only one client pod, every single WebSocket connection from that pod would be pinned to the same agent pod. All traffic, always, to one pod. The HPA could spin up ten pods under load and nine of them would sit idle while one gets hammered. The autoscaling is completely defeated.

Notice these are opposite failure modes. If the cookie is not preserved, stickiness never forms. If it is preserved, all traffic from one client pod pins to a single agent pod. Either way, the approach fails.

nginx consistent hash (rejected, but not obviously)

When I hit this problem I did what most engineers do, asked an AI assistant for the standard solution. Copilot gave me nginx consistent hash routing. It is technically the correct answer for this class of problem — routing a persistent connection to the same backend every time.

Here is how it works: instead of “round-robining” blindly, nginx can hash on a key you provide. Give it a run ID, it deterministically sends that request to the same pod every time. No randomness, no wrong pod.

The specific version that works for this problem: the client generates a UUID before calling POST to start the agent run and passes it as ?run_id=<uuid> in the query string. nginx extracts that same UUID from both the POST query param and the WebSocket URL path, hashes on it, and both requests land on the same pod. Perfectly even load distribution. Works at any replica count. No shared state needed.

I spent real time on this. It is a clean solution.

Then I found out it only works on staging.

Production uses Azure Application Gateway, a managed load balancer from Azure that sits in front of the cluster. AppGW handles SSL termination, routing, health checks, and more at the infra level. Unlike nginx, it does not support the upstream-hash-by annotation that makes consistent hash routing work. The feature simply does not exist on AppGW.

The answer was sitting in my own Helm chart the whole time. I had given Copilot the staging config but not the production one. It gave me the correct solution for the environment I showed it. I just hadn’t shown it the full picture.

Redis Pub/Sub with a namespace-local deployment (chosen)

Once nginx was off the table, the answer got simple fast.

The core insight is: instead of trying to route the WebSocket connection to the right pod, let any pod serve it. The pod running the agent publishes every event to a Redis channel. Any pod (whichever one the WebSocket connection lands on) subscribes to that channel and forwards events to the client. Pod routing stops mattering entirely.

I spun up a Redis instance as a separate deployment in the same Kubernetes namespace as my service. Not the shared Redis used elsewhere in the platform -- its own dedicated pod, completely independent, right next to my service.

This is literally all I added to my Helm chart:

extraManifests:
  - |
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: storefront-agent-redis
      namespace: platform
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: storefront-agent-redis
      template:
        metadata:
          labels:
            app: storefront-agent-redis
        spec:
          containers:
            - name: storefront-agent-redis
              image: redis:7-alpine
              command:
                - redis-server
                - --maxmemory
                - 200mb
                - --maxmemory-policy
                - noeviction
              ports:
                - containerPort: 6379
              resources:
                requests:
                  cpu: 100m
                  memory: 128Mi
                limits:
                  cpu: 250m
                  memory: 256Mi
              volumeMounts:
                - name: storefront-agent-redis-data
                  mountPath: /data
          volumes:
            - name: storefront-agent-redis-data
              emptyDir: {}
  - |
    apiVersion: v1
    kind: Service
    metadata:
      name: storefront-agent-redis
      namespace: platform
    spec:
      selector:
        app: storefront-agent-redis
      ports:
        - port: 6379
          targetPort: 6379

I will be honest: I do not fully understand every line of that YAML. But I do understand the nature of the solution and why the specific choices were made.

One thing worth understanding about Pub/Sub: Redis does not store these messages anywhere. When the agent pod calls publish, Redis finds all active subscribers on that channel and delivers the message immediately. Then it is gone — no key, no buffer, no replay. If a subscriber is not connected at that exact moment, the message is dropped. This is why emptyDir is fine: there is nothing durable to lose. MongoDB holds the real run state. The only thing Redis is doing here is wiring together a publisher and subscriber that might be on different pods.

MongoDB holds the real durable state for completed runs. Losing Redis mid-run means losing the in-flight WebSocket connection, but the run itself survives in MongoDB and can be retried.

One implementation detail worth keeping: I did not rip out the existing local queue. If the WebSocket connection happens to land on the same pod running the agent, events flow through the local queue directly, no Redis round-trip, lower latency. Redis is only used when the connection lands on a different pod. The fast path stays fast. Before this, a WebSocket landing on the wrong pod simply failed. Now it works regardless of which pod it hits.

Why this matters beyond the immediate fix

Here is a bonus I did not plan for. Future versions of this agent will need to pause mid-run and wait for a human to make a decision before continuing. That only works if the agent’s state is somewhere any pod can reach, not locked inside one pod’s memory.

By solving the WebSocket routing problem, that foundation is already in place. The event wiring is now pod-independent, and durable run state already lives in MongoDB, so the pieces for a future human-in-the-loop pause are mostly in place. Sometimes you get lucky.

The honest summary

The Redis implementation was done in a jiffy, once I knew what to build. The hard part was before that - watching non-deterministic failures, not knowing whether the problem was in the agent logic or the infrastructure, chasing the nginx solution because I did not know my own prod environment well enough to catch the mismatch.

Turns out it was the infrastructure. Probably worth understanding that layer before you need to debug it at 11pm.

Still figuring a lot of this out. If you’ve solved problems like this differently, I’d genuinely love to know. X or LinkedIn.

I am in Japan. December 2025. I am sitting across from the decision-makers of one of the country’s most respected heritage brands. And they are not happy. They are asking hard questions about our product. The kind that, if left unanswered, end partnerships.

My title? Technical Support Engineer.

I walked out of that same meeting with them going from unhappy to inviting me to their office. That wouldn’t happen if Swym ran a traditional support org. It happened because Swym doesn’t.

Because at Swym, titles are never really the full story.

Eshan somehow ended up carrying the heaviest box. Tokyo streets, December 2025.

Where It Started: Day One

I joined Swym as a Customer Experience Intern in January 2024. I was fresh out of VIT Vellore, curious, and had no idea what I was walking into.

The first signal that things would be different came early. Within my first few weeks, I wasn’t just resolving issues. I was being asked to understand why they happened. Senior engineers would walk me through root cause analyses. I was encouraged to exhaust every possible explanation before asking for help. The bar wasn’t “did you close the ticket.” It was “do you actually understand what went wrong.”

My first big debugging note earned a comment from a senior engineer, Kiran: “Good debugging by Eshan.” I have thought about that line more times than I can count. Not because it was flattering, but because it told me exactly what kind of place I had joined. Curiosity wasn’t a nice-to-have. It was the baseline.

At most companies, a support engineer is a translator: they turn a user complaint into a ticket and hand it to someone else who fixes things. What I found at Swym, from the very start, was that the expectation was different. You were meant to understand the problem well enough to fix it yourself wherever you could, and to make a genuinely useful contribution when you couldn’t.

Six months in, I converted from intern to full-time Technical Support Engineer. The title changed. The philosophy that had been shaping me from day one stayed exactly the same.

Growing Into the Role: The Part Nobody Warned Me About

Here is what nobody warned me about working at a fast-moving product company in a support role: the job grows with you, sometimes faster than feels comfortable.

Within the first year, I found myself doing things I had no formal training for: reviewing product launches before they went live, catching issues that would have affected thousands of merchants, and sitting in with the Product team not to give a quarterly summary of what support was seeing, but to work through actual merchant problems together so product decisions were made with real context rather than filtered reports.

I was writing documentation the whole team would use, mentoring junior team members, onboarding new senior hires, and contributing to discussions about where the product should go next.

None of this was in the job description. All of it was expected.

The moment that tested me most was when a new feature was close to shipping. There was momentum, there were timelines, and everyone was excited. But after my testing, I wasn’t convinced it was ready for merchants. So I said so. Brought the specific scenarios, the data, the reasoning. It was an uncomfortable call to make. The deployment was held, we fixed what needed fixing, and the launch happened cleanly.

Looking back, that moment taught me more about what Swym actually values than any onboarding document could. They didn’t want me to nod along. They wanted me to think, and then say what I thought, even when that was inconvenient.

Building, Not Just Supporting

Somewhere in the middle of all this, something shifted in how I thought about the job.

I had gone from someone who resolved problems, to someone building systems to prevent them. I was designing automation flows that would turn a support interaction into a product growth moment without any human needing to intervene. I was contributing directly to the codebase, acting as the primary support point of contact for third-party integrations, and doing work that at another company would have sat in an entirely different department with an entirely different job title.

A big part of what made this possible was Swym’s relationship with AI. While a lot of companies were still figuring out what AI even meant for their business, Swym had already committed to being AI-first. That wasn’t a slogan. It was a leadership decision that filtered into how every team operated, and it meant I was being actively encouraged to rethink entire workflows from scratch, to build things that had no precedent inside the company, and to move fast. Working here genuinely prepares you for the world as it is right now, and as it will be, not as it was five years ago.

A month I spent with the team in Bangalore crystallised this. It was 2am on more nights than I’d like to admit, learning tools I had never touched, rebuilding systems from scratch when a better approach emerged, all while keeping up with regular work. The kind of month that is genuinely hard while it is happening and, looking back, is exactly the thing that accelerated everything.

The Bangalore sprint. 2am sessions, new tools, and the kind of month that changes how you think about what you’re capable of.

The People. This Is the Part That Actually Matters.

I need to talk about something that is hard to put into words without it sounding like something off a careers page.

We are a remote-first company. That means fewer meetings, more async work, and a culture built around trust rather than presence. There was one particular team catchup in Bangalore where I wasn’t fully present. Something was going on personally, and I just wasn’t there mentally. I didn’t say anything. I figured I’d push through.

Arvind, our CEO, noticed. After the meeting, he set aside time just to sit with me and ask if I was ohkay.

Not a performance note. Not a follow-up task. Just: are you ohkay?

And that wasn’t the first time. In a remote-first company where the CEO is across time zones and carrying a hundred things at once, he still notices when someone on the team is off. That is not something you can fake or policy your way into. It is just who the people are.

Sonali, my manager, has pushed me in the best possible way: by genuinely seeing what I was capable of before I saw it myself, creating the conditions for me to get there, and having my back whenever it counted, even without me knowing.

AJ, my director, has been the person who gave me room to take on things well outside my lane, and trusted my judgment when it mattered. The fact that I ended up in Japan representing the company internationally is, in no small part, because of the confidence he placed in me.

And it is not just them.

I have disagreed with people senior to me. I have said “I don’t think this is right” in rooms where it would have been much easier to stay quiet. Every single time, I was heard. Sometimes I was right and changed the outcome. Sometimes I was corrected and learned something. But I was never, not once, made to feel that speaking up was a risk.

That psychological safety is rarer than most companies will admit. At Swym, it is just how things work.

The leaders at Swym are the kind I hope to become.

With Gopal, VP Swym, in Tokyo. December 2025.

Japan: Where It All Came Together

Back to that room.

In December 2025, I flew to Tokyo to represent Swym at a joint conference and dinner with merchants and agency partners across Japan. Not as part of a sales team. As the technical person on the ground, because my team believed I was the right person to be there.

Walking into that conference, it felt a little surreal. I had spent two years understanding this product from every angle, and suddenly I was using all of it in a room full of Japanese merchants and agency decision-makers, with a language barrier, no safety net, and real relationships on the line. But it also felt strangely natural. Like everything I had been doing had been quietly building toward exactly this kind of moment.

The conference was followed by an invite-only dinner with some of the most important agency partners in the market. The conversations were informal but went deep: technical gaps, product opportunities, what Swym could do better for the Japanese market. The kind of feedback that doesn’t come through a support ticket and doesn’t make it into a quarterly report unless someone was actually in the room to hear it. That is the kind of investment Swym makes, because when partners grow, the product grows, and it is the people on the ground who make that happen.

Swym put me on that ground.

I came back with new merchant relationships, strengthened existing ones, and market insights that fed directly into product planning. The work I did there shaped decisions that outlasted the trip.

That is what the role can become at Swym, if you let it.

The Swym x DotDigital conference, Tokyo. December 2025.

The invite-only dinner with some of Japan’s top agency partners.

What This Role Actually Is

If you’re considering joining Swym in a customer experience or support capacity, here is the honest version of what the job looks like.

You will handle support tickets. You will also shape the product. You will answer questions. You will also be the person who prevents those questions from ever needing to be asked. You will learn things you weren’t hired to know. You will be trusted before you feel ready. The work will expand to fill your curiosity, and then stretch a little further.

You will also be working in an environment that is genuinely AI-first, not as a talking point but as a lived reality. That means you will be expected to think about how AI can change the way you work, not just use the tools that already exist. In a world where AI literacy is fast becoming the most important professional skill there is, that kind of environment is rare and genuinely valuable.

The thing that makes Swym different is not just what you end up doing. It is that the people around you, at every level, are genuinely invested in your growth. You are not a headcount filling a function. You are someone they are actively trying to develop. And when something is going on with you personally, they notice.

In about two and a half years, I went from nervously resolving my first ticket to representing the company internationally, contributing to the codebase, achieving the highest quality audit score on the team, shaping product decisions, and mentoring people who are now starting the same way I did.

To Anyone Considering This

Swym is not for everyone. If you want clearly defined edges to your role and a scope that stays comfortable, this will push you in ways that don’t always feel good in the moment.

But if you want a place where the ceiling is defined by how far you’re willing to go, where the people above you are genuinely rooting for you, and where you will be treated like a person first and an employee second, I think you should take a hard look at this place.

I’m still a Technical Support Engineer. Depending on the week, I’m also a product quality gatekeeper, an automation builder, a technical presence in the field, and a mentor to people starting out exactly the way I did.

The title stayed the same. Everything else kept growing.

The Swym team. The people you’ll work with, grow with, and probably stay up until 2am with.

Eshan Sunam Bajaj is a Technical Support Engineer at Swym, working across product quality, AI automation, integrations, and merchant success. He joined as a Customer Experience Intern from VIT Vellore in January 2024. (Also posted here)

If you’re building a Shopify app that touches the storefront, you already know the pain. 1000+ themes in the Shopify theme store, countless custom and agency-built themes, and merchants who expect your app to just work regardless of which one they’re on. No configuration, no support ticket, no “please contact our team.” Just works.

That’s the bar we set for Wishlist Plus. Install it like you install Twitter on your phone. It works on day one, on your storefront, whatever that storefront looks like.

The mechanism we built to get there was theme presets, i.e a map of known themes to the exact CSS selectors needed to inject our UI correctly.

We use a productLinkSelector and an attachButtonSelector to position the wishlist button on a product card on collections grids. Our header implementation needs selectors to find the cart icon in the header and so on. Get the selectors wrong and the experience breaks. Get them right and it’s invisible (merchants never think about it).

The key to this whole system was theme_store_id. You look up the window.Shopify.theme.theme_store_id find your matching preset, apply the right selectors. This was the assumed approach. Inherited wisdom passed down through the codebase. Nobody had questioned it.

We should have questioned it sooner.

Theme presets aren’t new. Apps have been shipping selector maps since the Shopify’s ecosystem first matured enough to need them. The first principles haven’t changed, you still need to know which theme you’re on to inject correctly. What has changed is the scale. 1000+ themes, countless custom builds, and a theme identifier that was never designed to scale with the ecosystem it was supposed to describe.

The quiet tax

The failure mode wasn’t dramatic. The system didn’t fall over. What happened instead was subtler: when a merchant’s theme had no matching theme_store_id in our preset map, the experience broke for that merchant specifically. They’d raise a support ticket. Support would investigate, identify the theme, add the preset manually, fix it for that merchant. Everyone moved on.

On the surface, this looked like a support team doing its job. What it actually was: our automation silently failing for a large chunk of merchants, and humans absorbing the cost of a broken assumption in the codebase.

There’s no alert for “theme coverage is poor.” No dashboard that says “X% of installs fell through to the generic fallback.” What you get instead is a support queue that feels manageable, because you have no baseline to compare it against. The system looked healthy. It wasn’t.

We didn’t know how large those gaps were until we had the data to look.

The number that changed everything

We’d built an system that gave us real visibility into what was actually live on merchant storefronts. This was data we’d never had clean access to before. When we started re-examining our theme presets during a revamp of our Collections button, we pulled that data and looked at our theme_store_id coverage properly for the first time.

175k+ unique theme IDs in our dataset.

Only 66k had a valid theme_store_id.

That’s ~37% coverage. We were flying blind on 63% of the themes in our merchant base.

The assumption that had been quietly running our theme identification layer covered barely a third of the real world.

The fix was hiding in a changelog

We have Shopify’s RSS feed piped into Slack. While we were re-examining our preset logic, a changelog entry caught my eye: schema_name.

Shopify had introduced schema_name specifically to address the gaps in theme_store_id coverage, a more consistently populated identifier for theme identification. The question was how much better it actually was in practice. So we cross-referenced it against the same dataset.

140k+ of those same theme IDs had a valid schema_name.

Coverage jumped from 37% to above ~85%.

That was the moment. We refactored the entire theme identification layer to use schema_name as the primary identifier. The preset map that had previously keyed on theme_store_id now keys on schema_name. Every theme lookup, now running through the new identifier.

The before and after in the code was straightforward once the decision was made. The hard part was realising the decision needed to be made at all.

The honest caveat

This isn’t a complete solution. Custom and agency-built themes often have their own schema_name values that aren’t regulated by Shopify. We don’t maintain presets for those and we don’t want to, they’re one-offs that don’t scale. Those merchants still fall through to a generic fallback. It’s a known gap we live with.

Going from 37% to 85%+ coverage doesn’t mean the problem is solved. It means it’s dramatically smaller. The tickets that remain are genuinely one-off situations that need human attention regardless of which identifier you use. That's a different, more tractable problem.

What this means for you

If you’re building a Shopify app that relies on theme identification, presets, selector maps, theme-specific behaviour of any kind please check your theme_store_id coverage. Pull your data if you have it.If you don’t have the instrumentation to check, that’s a separate problem worth solving first.

You can read schema_name the same way you’d read theme_store_id, it’s right there at window.Shopify.theme.schema_name

And if you’re not monitoring Shopify’s RSS changelog, start. This fix was sitting in a changelog entry. It wasn’t announced loudly. It wasn’t in a developer blog post. It was just there, waiting for someone to connect the dots.

The dots were worth connecting.

Building on Shopify storefronts at scale? I’d love to compare notes. Find me on X or LinkedIn.

• 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!