Mehdi Salemi

Software engineer. Enterprise ecomm, Shopify & AI. Thinking about the systems behind commerce.

[Mehdi Salemi @mehdisdev]

@yeramianm Maybe this is why marketing teams exist lol. Devs ship it and call it a day 😅

[tobi lutke @tobi]

Our house in Toronto had this fancy glassed wine cellar, but we are not big wine drinkers.

Anyways, it had good climate control so here is my rack cellar.

[Mehdi Salemi @mehdisdev]

@JordanFinners Yea! At least we got some filters now haha!

[Mehdi Salemi @mehdisdev]

One Shopify platform feature I’d love to see: programmatic access to Shopify Function execution logs and metrics.

The Dev Dashboard already exposes a lot of the context you want when debugging Functions — individual runs, inputs/outputs, failures, shop context, timing, etc.

If apps could query that data, you could build a much better merchant-side observability layer.

Not just:

“Did the Function error?”

But:

Did this discount suddenly start applying way more often than expected?
Did a checkout customization stop executing?
Are failures isolated to a specific shop or configuration?
Did behavior change after a deploy?
Is one merchant-specific rule behaving differently from the rest?

Today you can approximate parts of this with webhooks, Admin API data, and your own application telemetry.

But the Functions runtime already has a lot of the most interesting execution context.

Expose that layer through an API and let apps build on top of it.

That could unlock a much stronger observability story for Shopify apps and merchants.

cc: @ShopifyDevs :) @nick_wesselman @dave_cameron

[Mehdi Salemi @mehdisdev]

@AlexHooper78640 Curious what you’d want to use network access for. My instinct is to avoid fetch calls in checkout if I can — sync the data ahead of time, stick it in a metafield, and read it through the Function input query.

What’s the use case you’re thinking of?

[Mehdi Salemi @mehdisdev]

Side thought: for larger enterprise teams, I still think webhooks + their own services are usually the better for core automation.

But if a team is already leaning on Flow, programmatic workflow creation/versioning could make it way more manageable.

Curious where others draw that line.

[Mehdi Salemi @mehdisdev]

Random Shopify Flow thought:

Would be pretty cool if apps could programmatically create/manage workflows.

Like install the app → create the Flow → wire up the triggers/actions/inputs → leave it disabled for the merchant to review/approve (or activate directly 😅).

Could be really useful for larger teams managing multiple stores / multiple Flows. Starts getting pretty close to “Flow as code” 👀

Wonder if the Flow team has ever thought about this. 🤔 @ShopifyDevs @thenuschke

[Mehdi Salemi @mehdisdev]

Haha what did they build / what did you have to fix? Feels like the bane of my existence lately lol. AI lets you move insanely fast, but then half the work is making the codebase understandable to humans again — separating things out, cleaning up boundaries, making the architecture obvious. Human documentation 🤣

[Mehdi Salemi @mehdisdev]

@armon_sho Are you on Shopify? I’m curious how are “Devs hacking checkout”

[Mehdi Salemi @mehdisdev]

Being remote, it’s nice to get out in the wild and talk to devs again. Checked out the ForwardJS Ottawa community tonight at Shopify 👋

[Mehdi Salemi @mehdisdev]

@t3d551 Fair!

[Mehdi Salemi @mehdisdev]

@dave_cameron I know a few apps that would happily build on top of it 👀🎉😆

[Mehdi Salemi @mehdisdev]

I do really like Flow when it becomes the merchant-configurable layer.

You can expose a custom trigger/action, keep the underlying logic in your app, and let the merchant configure the conditions in Flow — add tags, branch on order data, call something custom, etc.

You still get a decent amount of visibility into what the workflow did without burying everything in code.

Sometimes though, if the workflow is completely fixed, a plain webhook handler is just cleaner. Most of the time you end up in server logs for bugs anyway 🫠

[Mehdi Salemi @mehdisdev]

I love Shopify Flow, but I think its real power is orchestration — not becoming the business-logic layer.

Once you start packing Run Code actions with custom conditions, debugging gets messy fast.

Cleaner pattern IMO: custom Flow actions/extensions with explicit inputs, outputs, and logs — then let Flow wire them together.

Curious how other Shopify teams are handling this.

[Mehdi Salemi @mehdisdev]

The simplest version of the product is probably not “Datadog for Shopify.” I’d be thinking more like merchant-specific event monitoring.

Listen to the Shopify events that matter, then evaluate them against the business rules you actually care about. There are tons of webhooks. They won’t always include every field you need, but in a lot of cases you can use the Admin API / custom backend to hydrate the rest of the context before evaluating the rule.

Did a discount exceed the expected max?
Did a fulfillment happen without the payment capture you expected?
Did a product sync complete but required metafields are missing?
Did a refund happen without the expected return state?

Each check emits some signal like: OK / warning / failure, with expected vs actual.

Then you give the merchant one place to see those failures and alert into whatever they already use.

Webhooks cover “something happened.” You’d probably still need reconciliation / scheduled checks for “something should have happened but didn’t.”

That feels closer to the real observability gap than just another log viewer.

[Mehdi Salemi @mehdisdev]

@arjunvj93 From my time at Shopify, the platform side had strong observability — if something broke internally, it was alarmed 🫨.

The annoying part on the app/merchant side is there’s no clean layer to plug into. You usually integrate with whatever monitoring the client already has.

[Mehdi Salemi @mehdisdev]

Man, I’m still figuring it out tbh. Right now I feel like my max is two good sessions at once.

If I’ve got a bunch of smaller background tasks going, I try to make sure each one ends with solid docs + clear test steps.

For lots of small changes, I also like having PRs deploy to a test env so I can just click around and verify things. AI code reviews help too — Claude usually points me toward what’s actually worth checking.

[Mehdi Salemi @mehdisdev]

Interesting… I actually didn’t know that. I’ve been pretty deep in Shopify for a while and mostly see the other side, with bigger brands continuing to move onto it. Shopify also moves pretty quickly on what the platform can handle.

Curious from the finance side though: with those DIY/headless setups, are they still paying roughly the same processing costs they’d pay through Shopify? Or does owning payment routing change the money once you’re at that scale?

I’d assume the cost of building and maintaining that is pretty high. Part of Shopify’s value is taking a lot of that complexity off your plate.

But tbh, I’m also just a Shopify fanboy 🤣

[Mehdi Salemi @mehdisdev]

One thing I remember from Shopify: there was always a willingness to try things. From an engineer’s perspective, Shopify definitely felt ahead of the curve - AI wise.

The vibe felt like: "if it made sense, build it". If it stopped making sense, change direction. A prototype getting thrown away never felt like wasted engineering time. You learned something, moved teams if needed, and figured out what to build next.

Obviously sometimes the consequences were harder than that — layoffs, people quitting after changing teams, etc. But from what I saw, if you still wanted to build something meaningful in ecomm, there was usually another place to do it.

Agree with the broader point though - sunk cost shouldn’t win. #GSD