We Gave a Store Owner Claude in Production. Instead of a Meltdown, We Got a New Project!

Every developer I told reacted the same way: “You did what?”

We gave a non-technical store owner direct access to Claude Code — in their production Magento store. No dev sitting in the middle. No ticket queue. No “let me translate what you actually meant into something we can build.” Just the owner, an AI agent, and the live store they know better than anyone.

If you’ve worked in e-Commerce for more than a week, you already know the picture I’m about to show you.

That meme is funny because it’s true. It’s the gap every agency, every dev, every store owner has lived inside for decades — the slow, lossy game of telephone between what the business needs and what finally ships. Every round trip adds delay, cost, and one more chance to build the wrong thing.

I spent ten years on the wrong side of that gap

Here’s what nobody in my industry likes to admit: in ten years working at an agency, I never really saw how my clients ran their business.

We’d show up at the office for a day, maybe two. Take notes, nod, ask the right questions — then leave. Back at our own desks, we’d build from memory and a requirements doc. We talked about the business constantly; we were never in it.

I never sat behind an owner while they wrestled with the admin grid they use every single day. I never watched a manager give up on a built-in report and export to a spreadsheet instead. And once a project went live, that was usually the last we saw of it — the pain points that only surface after go-live happened in a building we weren’t in.

The only time that changed was freelance work — zzp’er (Freelancer, interim), on-site, sitting inside the business. Suddenly you see all of it: the workarounds, the muscle-memory clicks, the “oh, we just don’t use that feature, it’s broken.” That proximity is where the good work comes from. But it doesn’t scale, and agencies aren’t built for it.

That distance is the real reason the tree-swing gap never closed. It was never that developers are bad at listening. It’s that we were almost never in the room where the business actually happens.

We didn’t optimize that gap. We deleted it — by putting ourselves in the room, permanently.

The change itself was almost embarrassingly small: we put Claude Code in the browser and opened it up to the owner. What happened next is the part nobody warned us about — and the reason neither of us ever looked back.

The tiny change

For years, the setup was the same as everyone else’s. The store owner had an idea. They’d write it up, or hop on a call, or send a Loom. We’d turn it into a ticket. A developer would pick it up, spin-up dev environment, make the change, test it, and ship it. If we got it right, great. If we’d misunderstood — and we often had — we went back around the loop.

The change we made wasn’t a new tool or a clever framework. It was a decision: stop being the translation layer.

We put Claude Code in the browser — a shell that sits right on their store, running against their own environment and powered by their own Claude subscription — and opened it up to the owner. One link. No SSH, no terminal setup, no VPN, no “ask a developer first.” They open a tab and they’re talking to an AI agent that can actually do things in their store: read the catalog, adjust a config, investigate why an order didn’t import, draft a change and apply it.

The owner stopped describing what they wanted to someone who’d build an approximation of it. They just… asked for it. And got it.

“But WTF, $%^&%*% — production?!”

This is the part where most developers stop reading and start typing an angry comment, controversial so to say. So hear me out.

Pause for a second here... Let's try to take it from an objective point of view. I started my Magento journey as a UX major in eCommerce, not as a developer. And I can tell you one thing, AI is the best UX machine on Earth. (Tell you at the end, why is that).

And so let me asked you dear fellow developers,
Why don't we man'up and deploy on Friday evening then set it out?
Why do we even have discussions for when it should and shouldn't?

Here’s the thing the objection misses: the danger was never who was holding the tool — it was who and how much blast radius the tool had. A nervous developer, a junior pasting a command they half-understand can take down a store just as fast as anyone else.

I bet you at least for once, copy pasted StackOverflow snippets, trying to fix issues you can't.

“Only let experts touch production” was never actually a safety strategy. It was a bottleneck we’d mistaken for one. Those nightmares stories in Reddit where Terraform apply (without running the plan and apply on lock) deleted entire production and started new one with a success, I've been there too, lucky me, it was just one of the staging environment I can spin up with one click while having my coffee break.

So instead of restricting access, what we did:

• Decentralized agents and infrastructure. Customer bring their own infrastructure and their own Claude subscription. The blast radius stops at their store and nobody else’s. Lower risk of prompt-injection and cross contamination between environments. If it's being used for malicious attempts, it's at their own.
• The guardrails live in the platform, not in the person. The agent works inside boundaries we set per environment — what it can reach, what needs a confirmation — so safety is a property of the system, not a hope that the human won’t fumble. It's not bulletproof, agents are probabilistic, we must minimize the chances that happens.
• The same training, hands-off guide after production release. We can already pre-prepared skills, knowledge, mcp and really asked the customer what they would want to achieve, their biggest pain points. For instance: only allow sql read, not write.
• The Non-Tech user is not going to do what they don't know. The customer doesn't know what "rm -rf" does, it doesn't know sudo, it doesn't know docker. They know they are not developer, building it entirely themself is a desperate attempt. That means "we as a developer" have failed to identify the issues upfront and provided a suitable solution. A solid running shop doesn't need customer changing core config data 2am in the morning.
• Have a reality check. We all read horror stories with production and backup deleted with no way of restoring it. Yet with Claude and OpenAI is running on millions of devices today, for the mass from different background, we rarely seen anyone destroying their own computer week after week despite it has the capability to do so. Thats just because we "developer" can do more, the impact is greater.

Once safety is structural, the question “should a non-technical person have this?” stops being scary. It becomes obvious. The person with the most context about the business — the owner — is finally the one making the plan, instead of playing zoom meeting with someone like us who spents 24/7 in-front of a laptop screen.

And then the thing nobody predicted happened: production didn’t break. Not the first week, not the first month. If anything, it got 10x better.

• No more small changes request. You stopped getting small - day2day ops that took 10 seconds to do, but takes 5 min to change and another 10 min to asked if it's fixed.
• What they changed, automatically logged. We can traceback what the customer runs earlier with /resume, or simply asked the agent the entire summary of what the owner was trying to achieve. We can take it over, continue the conversation and the the owner can validate it's self by reading whats being done to remediate. This is called transparency. In directly also "tapped" into the owner chain of thoughts, made us understand them better.
• You will increase in revenue, if you bill by the hours. This happens to us. Customers started exploring, creating stuff. It's imperfect, we refine it. They do this three more times, it opens up their minds for new possibilities. It's billable hours. Everyone collaborate and everyone wins. No more asking apples get oranges.

To be clear: this isn’t for everyone

I’m not going to pretend direct production access is the right call for every store. It isn’t.

If your business runs under strict compliance, something like — ISO27001 / SOC 2 for your infrastructure, transactions every minute, a posture where every bit of production access has to be scoped, logged, and audited — then handing anyone ad-hoc access to a live system is a non-starter, and rightly so. Most built on least-privilege production access, separation of duties, and a hard line that changes get proven in a separate environment before they ever reach production. A non-technical owner poking around the live store doesn’t fit inside that — full stop.

But here’s the thing: production access was never the actual requirement. What the owner needs is a real environment that behaves exactly like their store — not a fake sandbox that lies to them.

So for a business like that, we don’t touch production at all. We give them staging — and we made spinning one up a single click. One button produces a complete, faithful clone of the live store — same catalog, same config, same code, same data, behaving exactly like production — in an isolated environment that can’t reach the live system.

The owner gets the identical experience: plan it, build it, test it, leave the console tab open on their call. The change is proven in staging, reviewed, and only then promoted to production through a controlled path — exactly the secure development lifecycle a compliance posture demands.

And it can go further still: in the strictest setups, production doesn’t need to be with us at all. StoreFrame becomes purely the staging layer — the secure development lifecycle (SDLC. SCA. SAST. DAST) where the owner and Claude Code plan, build, and prove every change against a faithful copy of the store.

Your live store can keep running on ie: Hypernode — or any host you already trust — with StoreFrame riding along as the staging sidekick where the agentic work actually happens. Best of both worlds: the hosting you’ve already vetted, plus an AI-native dev layer beside it. The finished, reviewed change ships to a production we never see, on your own infrastructure under your own controls — our blast radius into production is exactly zero, by design.

Same workflow. Same “no gap between what you wanted and what we delivered.” Just a blast radius of zero.

And this isn’t a fringe bet. The whole industry is already moving here. On Google’s earnings call, Sundar Pichai noted that over a quarter of all new code at Google is now AI-generated — “then reviewed and accepted by engineers.” That’s the tell: the senior engineer’s job is shifting from typing every line to shaping and approving what the AI produces.

In our own world, Magento educator Mark Shust is openly teaching developers to ship real work with Claude Code, develop his own HCF to aid developer creating Magento modules. Whether you give an owner production or keep StoreFrame as a staging-only SDLC layer, the underlying move is the same — and it’s already happening, with or without you.

What 10x actually looks like

Here’s how the "ideal flow".

The owner plans in their own environment — can be production or staging. They poke at what they want with Claude Code, get something roughly working, and then jump on a call with us and leave the console tab open. Now we’re all looking at the same thing: not a ticket describing a change, not a Loom approximating it — the actual plan, live, in front of all of us.

Together we talk through the real questions. What’s the risk? What are we worried about? We plan it out side by side, right inside Claude Code’s planning mode, until the plan is exactly what everyone wants — no ambiguity left to lose in translation.

On the same call we tighten the guardrails that need tightening, and — just as often — loosen the ones that were only ever there out of fear. When something comes up again and again, we capture it: a reusable skill, a guardrail, a recipe for exactly the kind of change this owner keeps asking for. The system gets smarter about this specific business every time we use it.

And that’s the whole trick. There’s no discrepancy left between what the store owner wanted and what the technical team delivered — because we planned it together, looking at the same thing, agreeing on it before a line of it ships. They ask for what they actually want. We build the exact same thing from our side. Nobody’s translating. Nobody’s guessing. 100 transparency.

The downstream effects surprised even us:

• No more buying modules for every small capability.
• No more waiting on license renewals to keep something working.
• No more guessing what you meant. We plan it together on the call — live, in Claude Code — so what gets built is exactly what we agreed on.

Save the time. Save the money. Nail the outcome. That’s where the 10x comes from — not from typing faster, but from deleting the entire loop between intent and delivery. This does not applies to a really big modules or themes thats on sensitive regions, but I can tell you 80% of it can be.

It’s not perfect. That was never the point, But Hey

Let me be honest: it isn’t flawless today. It wasn’t yesterday either.

Look at where AI was a year ago versus where it is right now — how much further it reaches, how much more it can safely do. That curve isn’t slowing down. The teams that win won’t be the ones who waited for it to be perfect. They’ll be the ones who built the habits, the guardrails, and the trust early — so that when the tooling gets better tomorrow (and it will), they’re already operating at the new ceiling instead of scrambling to catch up.

So yes — we gave a store owner access to Claude Code in their production (some staging only) Magento store. Everyone said it would break. It didn’t, maybe not yet. However it was an experiment we’ve made, and then...

We think outside the box, tested it, works! Should you do it? Thats your decision! Different business, different people, different industries, just different. Against all odds, it worked for us.