You Can Try to Vibe Code Your Commerce Stack, but Should You?

AI coding tools are powerful. But they still can't replicate everything a commerce platform handles at scale. Shopify's Field CTO breaks it down.

Every few days, an engineering leader sends me a LinkedIn DM or pulls me aside at a conference, with some version of the same question: "Our engineers are excited about vibe coding. Our CEO is asking what we actually need a commerce platform for. Can't we just build this ourselves?"

It's not a bad question. A year ago, the honest response was "you could try, but the work underneath is harder than it looks." That capability concern hasn't gone away. You still can't vibe code production payment infrastructure, or the data scale that powers conversion and fraud detection. Still, the AI coding tools your engineers are using every day are now powerful enough to build real commerce code, not just sandbox experiments. Your team can likely scaffold a storefront in a weekend. That's real, and it's worth taking seriously.

But the underlying work is more layered now. You need to think through which parts of your commerce stack can be vibe coded, which shouldn't be, which still need a platform underneath, and how your team stays in the loop on what does get built. That's a fundamentally different conversation, and it's the one engineering leaders need a framework for.

Here's how I think about it: If rebuilding it wouldn't change how a customer experiences your brand, buy it. If rebuilding it is where your brand's key differentiation or "secret sauce" lives, build it. Here's why.

Why "can we?" is no longer the only vibe coding question

The SaaS industry lost nearly a trillion dollars in market cap in February 2026, in what TechCrunch dubbed the "SaaSpocalypse."¹ Investor sentiment earned its own acronym: FOBO, fear of becoming obsolete. Whether or not you think that swing was overcorrected, the cultural shift behind it is real. And it's the reason this question keeps landing on my desk: do we still need a platform for this?

The analysts are engaging with this directly too. In March 2026, Forrester published "No, You Can't Just Vibe Code Commerce Yet."² Five of their analysts looked at vibe-coded commerce code and concluded it "may function but falls far short of being production-ready," and that commerce vendors themselves need to become what they call "vibe coding platforms."

That's a useful reference point, but the deeper issue is structural. The parts of commerce that can't be vibe coded aren't a limit AI tools will eventually catch up to. They're compounding advantages: payment infrastructure built on years of regulatory work, fraud and conversion systems informed by patterns across millions of merchants and billions of transactions, and peak-day reliability hardened through events like Black Friday Cyber Monday. The questions an engineering leader needs to work through are layered: what can be vibe coded, what should be, what still needs a platform underneath, and how to stay in the loop on what gets built?

Yes, you can scaffold a storefront in a weekend. That's not the hard part.

Anyone dismissing the vibe coding trend isn't being honest about what's changed. A competent team, with Claude Code or Cursor or any of the current generation of AI coding tools, can ship something that looks like a storefront in a few days. It will render. It will accept orders. It will look modern.

That's not a trivial achievement, and it's worth acknowledging rather than brushing off.

The trap is what comes after that weekend. What's been built is still a prototype that lacks the foundation required to ship; it probably can't accept payments, comply with regulators, stay online under real traffic, or run the operations behind the storefront.

Your technical team now has to build and maintain everything a commerce platform was actually doing for you:

• Payment processing at scale
• Integration with every other backend system that your company needs to run, from financials to warehouse management
• PCI compliance
• Fraud detection that improves the moment another business in the network sees a new attack pattern
• PII handling that keep customer information out of systems and AI tools that don't need it
• Global tax calculation as rules change quarterly across jurisdictions
• Checkout conversion optimization that compounds across millions of merchants
• Peak-day infrastructure that holds up when your traffic is many times normal volume
• B2B workflows, POS integration, multi-currency, and inventory sync across channels

And that list doesn't even include the operational infrastructure any production system needs: hosting, monitoring, deployment, and incident response. None of these are features. They're multi-year problems. Many of them outright prevent a compliant, smooth store launch. All of them are invisible when they work, which is exactly why they're easy to underestimate in the "can't we just build this?" conversation.

The cost of underestimating catches up. Deloitte recently projected that more than 40% of agentic AI projects could be cancelled by 2027 due to unanticipated costs.³ The same pattern shows up well beyond agentic AI: when the initial build feels fast, the long tail of ownership doesn't get factored in.

The real question: what should your engineers actually be building?

McKinsey framed the build-versus-buy question cleanly in their 2025 agentic AI report: build for differentiation, buy for operations.⁴

For commerce specifically, almost all of the infrastructure I listed above is operations. It's a table-stakes capability every brand needs before they even go live. At Shopify, that capability is the product of years of investment compounded across millions of merchants and billions of transactions. No single team building in isolation can replicate it.

Rebuilding it in-house doesn't change how your customer experiences your brand. It doesn't win you a new segment. It doesn't give your engineers a story to tell a recruiter. It's invisible work that takes engineers away from the work that would actually differentiate your brand.

For any engineering leader, the right framing is opportunity cost: "If we build this, what's the thing that would actually move our business forward that we're not building?"

That question almost always points in the same direction: your team should be spending their time on the parts of your business that are distinctly value-additive. Not on commerce infrastructure that a platform has already solved at a scale that no single team can match.

What Shopify gives you that you can't vibe code

Take Shopify as a concrete example of what that platform layer actually delivers. Some of it is technical. Some of it isn't. The hardest parts to replicate are the ones that depend on scale beyond any single business.

PII & security

Customer data has to stay protected at every layer it moves through, including the AI tools your team is starting to point at it. The platform handles that by default: each shop's data is isolated from other businesses through application-layer controls, AI tools follow your role-based permission structure, PII is scrubbed before any data is used to improve platform-wide models, and the whole thing runs on the same security infrastructure that protects millions of businesses on Shopify. Without a platform, the data hygiene layer is also yours to build and maintain. Every access boundary and every check that keeps a vibe-coded tool from pulling raw customer data into the wrong context becomes your team's problem to solve.

Network effects

Shop, Shopify's app and buyer network, has more than 250 million verified shoppers worldwide. When a buyer lands on your store and is already recognized by that network, they convert at rates up to 50% higher than guest checkout via Shop Pay.⁵ You can't vibe code that. It's the accumulated result of millions of merchants participating in a shared system. The network is the feature.

Commerce intelligence

With millions of businesses on Shopify, the platform sees an enormous breadth of commerce. Aggregated and de-identified data across the platform trains the Shopify-operated models behind Sidekick, Search & Discovery, and other capabilities, and powers product data enrichment that improves discoverability across surfaces, including AI channels. A custom-built fraud system starts from square one. Shopify's platform learns from the scale of the network and improves every day.

Peak-day infrastructure

Black Friday and Cyber Monday 2025 on Shopify processed $14.6 billion in sales, with peak traffic of 489 million requests per minute and 99.9% uptime.⁶ Infrastructure that holds up at that scale takes years of chaos engineering, load testing, and hardening, all invisible until the moment it matters.

Research & development velocity that compounds in your favor

A platform with thousands of engineers is shipping capability every day that the brands using it benefit from without having to build it themselves. Twice a year, Shopify Editions ships hundreds of product updates to brands on the platform in a single release. Every feature that ships is one your team didn't have to write, maintain, or keep compliant.

None of this is a reason to give up on building. It's a reason to be intentional about where your building energy goes.

Where vibe coding actually belongs

Here's the part of the conversation I enjoy most. Once an engineering leader stops asking whether they need a platform and starts asking where they should be building, the answer gets interesting fast.

Your first line of code should be differentiation, not infrastructure.

Personalized customer experiences that reflect your brand in ways a template can't. Integrations into the specific systems that run your business. Internal tooling that makes your merchandising or operations team faster. Bespoke workflows for your category. The places where your edge lives as a business are the places your engineers should be pointing AI coding tools.

The best commerce platforms are purpose-built for this. They expose the primitives, they don't lock you into the storefront. They assume you'll extend them, and they make that extension safe by not requiring you to rebuild anything underneath.

That's the model worth building on: a foundation you don't have to maintain, with an open surface on top where your team can move as fast as the AI tools allow.

The way we think about this at Shopify is straightforward: building on top of the platform should be the most modern, simple, AI-native experience possible for the next generation of developers. The Shopify AI Toolkit is one piece of that. It gives the AI coding tools your engineers already use, like Claude Code, Cursor, Codex, Gemini CLI, and VS Code, direct access to the platform's documentation, API schemas, and code validation.

And we're not stopping there. Shopify is building aggressively across every surface where brands are working with AI, because we believe the platform should be part of every conversation your team is having about how to ship with these tools.

Our partnership with Lovable is another example. Where the AI Toolkit gives your engineers a richer environment to build in, Lovable opens commerce building up to people who don't write production code: they can stand up a working Shopify storefront by describing what they want in natural language, with checkout, payments, and the rest of the infrastructure handled underneath. Different surfaces, same idea: the foundation is handled, the edge is yours to build.

The AI Toolkit and the Lovable integration both handle the "how" of vibe coding well. The harder problem is the "what." Which work belongs on top of the platform, and which work belongs to the platform itself?

How to draw the line for your team

It's worth restating, because this is the rule my team and I keep coming back to with engineering leaders:

If rebuilding it wouldn't change how a customer experiences your brand, buy it. If rebuilding it is where your brand's edge lives, build it.

The rule is deliberately sharp. Payments infrastructure doesn't change how a customer experiences your brand. Your custom merchandising logic for a specific product category absolutely does. A fraud system doesn't change how a customer experiences your brand. Your post-purchase upsell flow, designed around your specific buyer, absolutely does.

The rule will feel uncomfortable in the moment, because vibe coding makes more things feel buildable than ever before. That's exactly why the rule matters. The real constraint is where your team's time generates returns that compound.

Drawing the line is the first half of the job. Keeping a human in the loop on what actually ships is the second half. Even on work that's right to vibe code, the human controls matter: governance over what gets built, oversight on what gets shipped, and proactive guardrails on what an agent can do unattended.

AI coding tools move fast enough that an unsupervised agent can push code in minutes, and a human engineer still needs to review every change that touches your customers, your data, or your operations before it goes live. The rule above only holds up if there's a person on your team verifying every shipped change against it.

Build differentiation. Buy infrastructure.

The answer I give engineering leaders, every time: build your differentiation. Buy your infrastructure. Let the platform compound underneath you while you compound on top.

That's how your engineers spend their time on work that actually moves your business forward. The honest answer to "can't we just build this ourselves?" comes down to leverage.

Yes, you can build pieces of it, and the pieces you can build keep getting larger. No, you shouldn't build the parts where a platform is already compounding scale, data, and reliability across millions of merchants. The job of an engineering leader is to know which is which, and to point your team at the work only your team can do.

Sources

1. TechCrunch, "SaaS in, SaaS out: here's what's driving the SaaSpocalypse," Mar 2026
2. Forrester, "No, You Can't Just Vibe Code Commerce Yet," Mar 18, 2026 (five-analyst position paper concluding that commerce vendors must become "vibe coding platforms")
3. Deloitte, "TMT Predictions 2026: SaaS, AI agents, and unanticipated costs," 2026 (40%+ agentic AI project cancellation projection)
4. McKinsey, "Seizing the agentic AI advantage," Jun 2025 (build for differentiation, buy for operations)
5. Based on a study completed in April 2023 in partnership with a Big Three global management consulting company.
6. Shopify SEC filing, "BFCM 2025 Press Release," Nov 2025 ($14.6B processed, 489M req/min at peak, 99.9% uptime)