Building AI-native
Shopify apps: what the
open toolkit changes.

Here's the number that matters for anyone building a Shopify app in 2026: teams that adopted Shopify's AI Toolkit are reporting 40 to 60 percent less time on typical admin-workflow development. Not a marketing claim about productivity in the abstract. A real, measured compression in the hours it takes to ship the kind of app that lives in the Shopify admin. That single fact rearranges almost everything about what an app is worth and where its defensibility actually comes from.

Two things drove it. Shopify shipped its Dev MCP Server inside the Winter '26 Edition in December 2025, giving coding agents structured access to the platform's docs, schemas, and operations. Then on April 9, 2026, the company open-sourced the AI Toolkit under an MIT license, free, on GitHub, connecting agents like Claude Code, Cursor, Codex, Gemini CLI, and VS Code directly into Shopify's APIs. The build experience went from reading docs and writing boilerplate to describing what you want and letting an agent scaffold it, validate it against the live schema, and run it.

I've watched a lot of Shopify apps get built. I helped build the partner program as an early Shopify employee, founded and sold a software company to Tiny, and I now advise app founders scaling toward $100M. So I want to be precise about what this does and doesn't change. It does not make app businesses easier. In some ways it makes them harder, because when the build is cheap, the build stops being the thing you compete on. The advantage moves somewhere else, and a lot of founders are going to keep optimizing the part that no longer matters.

This is the long version of that argument. What actually shipped and what it does. What "AI-native" really means versus bolting a chat box onto an app you already had. The new build workflow with agents, GraphQL, UI extensions, Liquid, and Hydrogen. How agentic commerce and the surge in AI-referred traffic change which apps are even worth building. And the strategic part that most of the coverage skips: when builds get cheap, the moat moves to distribution, data, and workflow depth, which reshapes app economics and what these businesses are worth.

If you're a founder, the practical question isn't "should I use the AI Toolkit?" Of course you should; your competitors already are. The real question is what you do with the time it frees up, because that decision is now the whole game.

What actually
shipped, and why
it matters.

Two releases changed the build experience. In December 2025, the Winter '26 Edition shipped Shopify's Dev MCP Server, which gives AI coding agents structured access to the platform. Then on April 9, 2026, Shopify open-sourced the AI Toolkit under an MIT license, free on GitHub, exposing seven tools that let an agent search the docs, validate queries against the live schema, and execute real store operations. Together they turn "read the docs, write the code" into "describe it, and the agent builds and checks it."

The mechanics are worth getting right, because the marketing version blurs them. The AI Toolkit is an MCP server. It connects coding assistants, Claude Code, Cursor, VS Code, Gemini CLI, OpenAI Codex, to three things: Shopify's current documentation, its GraphQL schemas, and a CLI-backed store-execute capability. You install it with a single command. From that point your agent can look up the right API without you tabbing to a browser, generate a GraphQL query, and have it checked against Shopify's actual current structure before it runs.

That third capability, store execute, is the one that surprises people. It isn't just code generation. Through the Shopify CLI, the agent can perform real operations on a live store: creating and updating products, managing metafields, modifying theme files, running bulk operations. A developer describes the change in plain English, and the agent translates it into the correct API calls, validates them, and executes them. The boilerplate layer, the part that used to eat a sprint, gets handled by the agent so the developer spends time on decisions and quality control instead.

Why does the validation piece matter so much? Because the single biggest tax on Shopify development was always the gap between what you thought the API did and what it actually did this week. Shopify ships constantly. Docs drift. The old loop was write, deploy, hit an error, search, fix, repeat. When the agent has the live schema and validates before running, that loop collapses. You're catching the mismatch before it ships, not after a merchant's store breaks. That's a quieter benefit than "build apps from plain English," and it's the one that actually compounds.

The seven tools are worth understanding individually, because "an MCP server" is abstract and the capabilities are concrete. Broadly they fall into three jobs. There are documentation tools that let the agent search and read Shopify's live docs without leaving the editor, so it's reasoning from the current API rather than whatever was true when its training data was cut. There are schema and validation tools that check generated GraphQL and Liquid against Shopify's actual current structure before anything runs. And there's the store-execute tool that performs real operations through the CLI. The split matters: the first two make the agent accurate, and the third makes it active. A lot of AI coding help is one without the other. This is both.

It's also worth naming what this is part of. The Winter '26 Edition was explicitly framed as "AI-native, developer-ready." Shopify isn't bolting an assistant onto its developer experience as a side feature. It's making the platform itself agent-legible, the same Dev MCP whether you're in Cursor, Claude, or the dev assistant on shopify.dev. When the platform owner makes that kind of structural bet, app founders should read it as a signal about where the whole ecosystem is heading, not a convenience to opt into when they get around to it.

I want to flag one thing the open-sourcing changes that the docs don't emphasize. An MIT license means this isn't a Shopify-controlled black box you depend on at their pleasure. The community can read it, fork it, extend it, and build on top of it, which usually means the surrounding tooling improves faster than any single vendor could ship. For a founder, that's a reason to lean in rather than wait. The ecosystem of agent-assisted Shopify development is going to compound around an open standard, and the apps that integrated early with that workflow will be the ones that benefit as the tooling around it gets better. Sitting it out to see how it shakes out is the expensive choice here.

The 40-60% cut, and
what it actually
frees up.

The headline figure is real and specific: teams that adopted the AI Toolkit report 40 to 60 percent less time on typical admin-workflow development. The work that compresses is the predictable middle of a build, documentation lookup, implementation, testing, debugging, the stuff that used to span a full sprint cycle now folds into single sessions where the agent handles research and the developer makes the calls. That's where the hours go.

But a productivity number is only interesting if you know what it does to the rest of the business. Cutting build time in half doesn't mean you ship the same roadmap with half the team and pocket the difference. It means the cost of producing a given feature just dropped for you and for everyone else, including the competitor who hasn't shipped yet. A cheaper build is a lower barrier to entry. The 40-60% is good news for your burn and ambiguous news for your moat, and treating it as pure upside is the first mistake.

So what should the freed-up time actually buy? Three things, in order. First, more shots on goal at the parts of the product an agent can't reason about, the workflow judgment, the edge cases specific to how real merchants operate, the integrations that require taste. Second, faster iteration loops with customers, because the bottleneck moves from "can we build it" to "do we understand the problem," and that's a research problem, not an engineering one. Third, the discipline to not ship everything you now can, because feature sprawl is cheaper to produce and just as expensive to maintain.

There's a labor-market wrinkle inside the 40-60% that founders should think through honestly. If the boilerplate layer is now agent-handled, the value of a junior developer whose job was mostly that layer drops, while the value of a senior developer with the judgment to direct the agent and catch its mistakes rises. For a small app team, that can mean staying smaller longer, which is good for burn but changes how you hire. The skill you're now paying for is taste and merchant understanding, not raw production throughput. Hiring for the old profile, "ships a lot of code fast," is hiring for the thing the Toolkit just commoditized.

I keep coming back to a simple reframing for the founders I advise. The AI Toolkit didn't give you a faster horse. It changed what the race is about. When building was slow and expensive, "we built it well and fast" was a defensible answer to why a merchant should choose you. Now that answer is available to everyone, so it defends nothing. The teams that win the next two years are the ones that take the time the Toolkit gives back and reinvest it in the things that stay hard: understanding the merchant, owning the distribution, and accumulating data nobody else has.

What "AI-native"
actually means for
an app.

Here's the test that cuts through the marketing: pull every AI feature out of your app, and ask whether it still works. If it functions fine as a tool without the model calls, the AI was bolted on. If the product collapses or becomes non-functional, it's AI-native. That's the whole distinction, and most apps calling themselves AI-native in 2026 would fail it. They added a chat box. They didn't rearchitect.

The difference isn't cosmetic, it's structural. An AI-native app architects intelligence into the data model, the workflows, and the surface from day one. The model can read live store state, reason over it, take action, and adapt to what it sees. A bolt-on routes every AI request through legacy middleware before it reaches the model, which produces the "lag-and-wait" experience merchants notice. Worse, the bolted-on AI usually can't see real-time state, so it operates in a vacuum and hallucinates, confidently telling a merchant something about their store that isn't true.

Why does this matter strategically and not just technically? Because the bolt-on path is the trap the AI Toolkit makes most tempting. It's never been easier to wrap an LLM around your existing app and ship "AI-powered" on the listing. Thousands of apps will do exactly that this year. They'll create what the industry has started calling a franken-app: 2010-era architecture with an AI veneer, slow, context-blind, and replaceable by the first competitor who built the workflow around the intelligence instead of beside it. The ease of the bolt-on is precisely why it's not a moat.

I think about this the way I think about what AI-native looks like on the brand side. A brand that bolts AI onto a few marketing tasks gets a marginal efficiency. A brand that rebuilds its operating model around it gets a structurally lower cost base. Apps are the same. The question isn't whether you use AI. Everyone uses AI now. The question is whether the intelligence is load-bearing, whether removing it would break the thing your merchant actually relies on. That's the only version that's hard to copy.

Let me make the difference concrete, because it's easy to nod along and still get it wrong. Take a merchandising app. The bolt-on version adds a chat box where a merchant can ask "what should I feature this week?" and gets a generic answer, because the model doesn't actually see the store's live inventory, margin, or sell-through. The AI-native version is built so the intelligence reads real-time stock levels, contribution margin per SKU, and recent velocity, then proposes a merchandising plan grounded in that store's actual state, and acts on it by updating collections. Same category, same surface-level pitch. One is a feature you'd never miss if it broke, the other is the product. The merchant feels the difference within a week.

Or take customer support. A bolt-on wraps a chatbot around your existing ticketing app and calls it AI. An AI-native support app is architected so the model has live access to the order, the fulfillment status, the return history, and the policy logic, and can actually resolve the issue rather than draft a plausible-sounding reply that a human still has to check. The bolt-on saves a few keystrokes. The native version removes the human from the loop for the cases that don't need one, which is a structurally different value proposition and a structurally different price point. The architecture is the product decision, not an implementation detail.

There's a nuance founders should sit with. Not every app needs to be AI-native, and chasing the label for its own sake is its own mistake. Some categories are genuinely about reliable plumbing, and a merchant doesn't want a model improvising on their tax logic or their inventory sync. The honest question is narrower: in your category, is there a workflow where intelligence in the core changes what the product can do, versus where it just adds a feature? If yes, building native is the durable choice. If no, be the most reliable plumbing in the category and don't pretend. Mislabeling a bolt-on as native fools the listing, not the merchant.

The new build
workflow, end
to end.

With the Dev MCP and the AI Toolkit wired in, an agent can now handle the full development workflow end to end: scaffolding apps, running GraphQL operations, and generating validated code across Admin, UI extensions, Liquid, and Hydrogen. That's the whole surface area of a modern Shopify app, and an agent can move across all of it in one session. The developer's job shifts from typing the code to directing the build and owning the judgment.

Walk through what that looks like in practice. You describe the app you want. The agent scaffolds the project structure. It writes the GraphQL queries and mutations against the Admin API and validates them against the live schema before they run, so the integration is correct on the first pass instead of the fifth. It generates the UI extensions that put your app inside the admin where merchants work. It handles the Liquid for theme-facing pieces and the Hydrogen for custom storefronts. Each layer that used to be its own specialist task is now something the agent produces and the developer reviews.

The part that genuinely changes the calculus is agentic flows. You can now build agents that take a shopper from discovery to purchase, search, selection, and checkout via Checkout Kit, entirely within the agent experience, creating full agentic flows for the first time. That's not a faster way to build the app you were already building. It's a new category of app that wasn't really possible before: software that participates in an agent-driven purchase rather than just rendering a page for a human to click through.

Does this mean developers are optional? No, and the founders who read it that way will ship broken apps fast. The agent compresses the research and boilerplate layer. It does not replace the decisions: what to build, how the workflow should feel for a real merchant, where the edge cases live, what to refuse to ship. If anything, the developer's taste matters more now, because the bottleneck moved from production to judgment, and bad judgment produces bad apps at a much higher rate than it used to. The skill that's scarce isn't writing the GraphQL. It's knowing which app is worth writing it for. That's the same shift I keep flagging in the practical guide to building a Shopify app this year.

One operational caution from having watched a lot of these builds. Validated-against-the-schema is not the same as right-for-the-merchant. The agent will happily generate a technically correct mutation that does a subtly wrong thing for how a particular store operates, and it'll pass every check. The discipline that protects you is the same as it always was: test against real merchant scenarios, not just against the schema. The Toolkit removes the syntax errors. It doesn't remove the need to understand the business you're building for, which is exactly the part that stays hard.

Old build versus
AI-native build:
what moved.

The clearest way to see the shift is side by side. The same app, built the old way and built the new way, isn't just faster in the second column, it's a different shape of work. The hours collapse on production and shift to judgment, and the thing you compete on moves from execution to everything execution used to crowd out.

Read the bottom two rows carefully, because they're the whole point. When time moves from production to judgment, and competition moves from build speed to distribution and data, the spreadsheet of your business changes underneath you. Engineering becomes a smaller share of what determines whether you win. The functions that used to be "everything we couldn't get to because we were heads-down building" become the functions that decide the outcome.

There's a trap hiding in the left column that founders should notice. Every cell in "old way" was a place where a well-run team could out-execute a sloppy one. Tight scaffolding, clean GraphQL, fast debugging, these were real, earned advantages, and they're the ones the Toolkit just commoditized. If your company's identity is built around being the team that ships clean code fast, the Toolkit didn't help you, it erased your edge. That's an uncomfortable thing to sit with, and it's exactly why the strategic response matters more than the tooling adoption.

The encouraging read is the right column. Everything that's now decisive, distribution, proprietary data, workflow depth, merchant trust, is something that compounds and resists copying. A competitor can match your feature in a weekend now. They can't match three years of install base, a data asset they don't have, or the trust you've earned with merchants who've run your app through two peak seasons. The Toolkit moved the competition onto the terrain where time and relationship actually count for something, which is better terrain for a serious founder than a code-speed race ever was.

When the build gets
cheap, the moat
moves.

This is the strategic core, so let me state it plainly: when an agent can reproduce your feature in a fraction of the old time, the feature stops being a moat. Defensibility moves to the three things agents can't copy quickly, distribution into a roughly 13,000-app store where the average merchant runs about six apps, proprietary data and the workflow depth it unlocks, and the install base and trust that take years to build. Code got cheap. These didn't.

Start with distribution, because it's the most under-appreciated. The Shopify App Store has more than 13,000 apps and the average merchant installs around six. That's a brutal funnel. Being discoverable, ranking, getting installed, and surviving the merchant's periodic app-stack cleanup is harder than building the app in the first place, and the Toolkit did nothing to make it easier. If anything it made it worse, because cheaper builds mean more apps competing for the same six slots. The founders who win understand that distribution is now the primary product. I've written the full distribution playbook separately, and it matters more in 2026 than it ever has.

Then data. An agent can rebuild your features, but it can't hand a competitor the data you've accumulated, the merchant behavior, the outcomes, the patterns your app has seen across thousands of stores. That data is what lets an AI-native app actually be intelligent rather than generic, and it's the asset that compounds while everything around it commoditizes. A competitor starting fresh with the same Toolkit and a better-funded team still starts with zero data. If your app generates a proprietary dataset as it runs, you have a moat that gets deeper every day, which is the opposite of a feature.

Third, workflow depth and trust. The apps that survive are the ones embedded so deeply in how a merchant operates that ripping them out is genuinely painful. That depth, the integrations, the muscle memory, the accumulated configuration, the trust earned across peak seasons, is the slowest thing to build and the slowest thing to dislodge. A shallow app is a feature a merchant tries and churns. A deep app is infrastructure a merchant won't risk replacing. The Toolkit makes shallow apps trivial to produce, which makes deep apps relatively more valuable, not less.

I learned this lesson the hard way and the right way at the same time, from two angles. On the merchant side at WIN Brands Group, we ran a stack of apps across a portfolio of stores, and the ones we never even considered replacing weren't the cleverest, they were the ones woven into a daily workflow nobody wanted to relearn. Switching cost is real, and it's mostly human. On the software side, building and selling getuptime.co, the value a buyer underwrote wasn't the code, which a competent team could have rebuilt. It was the install base, the retention, and the relationships. That's the whole lesson of this section, lived twice: the durable asset was never the build.

Here's the reframe I'd push hardest on. Founders tend to treat distribution, data, and depth as things you get to after you've built a great product. In a world of cheap builds, that sequence is backwards. The product is now the fast part. Distribution, data, and depth are the slow parts, which means they should be the things you start building deliberately from day one, not the afterthought you turn to once the feature set is done. A founder who spends month one obsessing over the App Store listing, the partner relationships, and the data model that will compound is ahead of a founder who spends month one perfecting code that an agent could have written in an afternoon.

Agentic commerce
changes what's worth
building at all.

The other half of this story is demand, and it's moving fast. AI-driven traffic to US retail sites grew 393 percent year over year in Q1 2026. AI-referred orders on Shopify grew roughly 13x over the same period, and by March 2026 AI traffic was converting about 42 percent better than baseline, with revenue per visit from AI referrals running well above non-AI traffic. The funnel is changing shape, and apps built only for the old human-clicks funnel are building for a shrinking share.

So which apps are worth building now? The ones positioned on the agentic-commerce surface, where the growth is. Apps that make a catalog legible to AI agents, that feed clean product data into shopping assistants, that instrument and attribute AI-referred conversion so merchants can actually see it, that participate in agent-driven checkout. These aren't speculative bets on a future that might arrive. The traffic already grew 393 percent. The question for a founder is whether your roadmap is pointed at where demand tripled or where it's flat.

This is where the Toolkit's agentic-flow capability connects to a real market. Shopify made it possible to build agents that take a shopper from discovery to checkout for the first time, exactly as the traffic to support that experience exploded. That's not a coincidence; it's a platform aligning its developer tools with where commerce is heading. A founder who builds for agent-driven purchase isn't betting on a trend, they're building for the channel that's already growing 13x in orders. I've mapped the merchant side of this in the guide to agentic commerce for brands, and the app opportunity is the mirror image of it.

What gets less interesting to build? The hundredth variation on a problem the platform is quietly absorbing. Shopify keeps shipping native capability, and 42 percent of merchants already use its built-in AI features like Sidekick and Magic. An app whose whole value is a thin wrapper on something the platform now does natively, or will soon, is building on sand. The durable opportunities sit in the gaps the platform won't fill, the deep vertical workflows, the data-rich niches, the integrations too specific for a platform owner to bother with. That's the same lens I apply in the broader look at how AI is reshaping the app landscape.

Let me get specific about categories, because "build for agentic commerce" is too abstract to act on. A few concrete opportunities I think are genuinely worth a founder's time right now. First, catalog-to-agent infrastructure: apps that take a merchant's messy product data and make it clean, structured, and legible to shopping agents, so the merchant's products actually surface and get bought in agent-driven discovery. Second, AI-referral attribution and analytics: merchants can see that AI traffic converts 42 percent better but most have no idea which assistant sent it or what to do about it, and the app that instruments that becomes the system of record for a fast-growing channel. Third, agent-facing conversion tooling: apps that participate in the agent's path to purchase rather than just optimizing a human's. Each of these points at the surface that grew 393 percent, not the one that's flat.

And a few categories I'd be cautious about. Anything that's a thin layer on a capability Shopify is clearly moving toward natively is a hard place to build a company, however easy it now is to build the app. Generic AI copywriting, generic chatbots, generic recommendation widgets, these are getting commoditized from two directions at once: the platform absorbing them and the Toolkit making clones trivial. That doesn't mean nobody makes money there, it means the money goes to whoever already has distribution and the data, not to a new entrant with a marginally better version. If you're starting fresh, point at the gaps, not the crowded middle.

A blunt question I ask the founders I advise: if Shopify shipped your app's core feature natively next quarter, would your business survive? If the honest answer is no, you're not building a company, you're building a feature on borrowed time, and the AI Toolkit just shortened the runway by making your feature cheaper for everyone, including the platform, to reproduce. The apps worth building are the ones where the answer is yes, because the value lives in data, distribution, or depth that the platform can't or won't replicate.

What the Toolkit does
to app economics
and valuations.

The economics still favor building, but the value drivers shifted. Shopify's app ecosystem generates around $890 million in annual developer revenue, and developers keep 100 percent of their first $1 million in lifetime App Store revenue before the 15 percent share kicks in. That's a real on-ramp, and it didn't change. What changed is that a cheaper build means the same feature attracts more competitors, so the value of "we have this feature" fell while the value of durable revenue rose.

For valuation, the practical effect is that buyers and investors underwrite the things that survive commoditization. Net revenue retention, install base, the data asset, the depth of workflow lock-in, these are what a serious acquirer pays for, because they're what a competitor with the same Toolkit can't reproduce. Feature count was never a great proxy for value, but in 2026 it's actively misleading, because the feature a competitor would have needed two quarters to copy now takes them two weeks. The durable number is retained revenue, and the multiple tracks how defensible that revenue is. I go deeper on the mechanics in how a Shopify app actually gets valued.

Pricing is where a lot of founders will leave value on the table. When the cost to produce a feature collapses, the instinct is to compete on price, and in a commoditized feature market that instinct is fatal, because someone will always undercut you to zero. The escape is to price on the outcome the app delivers and the depth it's embedded at, not on the cost to build it. An AI-native app that drives measurable revenue for a merchant can charge against that revenue, and that pricing holds even as build costs fall, because the merchant is paying for the result, not the code. I've laid out the options in detail in the app pricing strategy breakdown.

It's worth being concrete about who's buying and what they're now underwriting, because the buyer pool changed alongside the tooling. Strategic acquirers and the larger app consolidators aren't paying for a feature list, they never really were, and they're paying even less for it now. They're paying for a book of retained, paying merchants, a data asset that improves the product, and a position in a category that's hard to enter. When the build cost of the underlying app falls, the implicit message to a buyer is "you could rebuild this," so the only thing left to actually buy is the stuff you couldn't rebuild: the customers, the data, the trust. That's why the multiple increasingly tracks retention quality, not the cleverness of the code.

There's a wider context that frames all of this. Shopify's own valuation compressed to roughly 10x sales, well below its multi-year average, as the market repriced what platform and ecosystem businesses are worth. That repricing flows down to apps. The era of paying a premium for any SaaS with a growth curve is over, on the platform and in its ecosystem, and the apps that command real value are the ones with profitable, retained, defensible revenue. The Toolkit accelerates that sorting, because it strips away the build-cost advantage that used to flatter weaker businesses.

One subtle dynamic worth naming for anyone thinking about an eventual exit. Cheaper builds compress the value of early-stage, feature-only apps and raise the relative value of mature apps with real retention, because the gap between "anyone could build this" and "almost nobody could acquire this base" widens. If you're early, that's a reason to invest in the durable assets fast, before a wave of cheap clones arrives. If you're mature, it's a reason to recognize that your retained revenue and data are worth more in this market, not less, even as the broader SaaS multiple environment stays disciplined. The Toolkit didn't make app businesses worth less across the board. It widened the spread between the ones with a moat and the ones without.

The optimistic read, and I think it's the right one, is that this is a healthier market for a real founder. When builds were the bottleneck, capital and engineering throughput could paper over a weak business. Now that builds are cheap, the businesses that win are the ones with genuine distribution, real data, and deep merchant relationships, and those are exactly the things a committed founder can build that a well-funded clone can't buy. The Toolkit punishes the businesses that were only ever a fast build, and it rewards the ones that were always about something more durable. If you're building the durable kind, this market is better for you, not worse. The path from a working app toward real ARR runs through the same fundamentals I lay out in the MVP-to-$1M-ARR walkthrough.

The founder's
phase-stack for
going AI-native.

If you're a founder deciding how to respond, don't start by rewriting your app. Start by deciding where the durable value will live, then build toward it. Here's the sequence I walk founders through, designed so each phase produces something defensible rather than just something shippable. The whole point is to spend the time the Toolkit gives back on the parts that stay hard.

A note on sequence, because order matters as much as the steps. Adopting the tooling is fast and everyone will do it, so it's necessary but worthless as an advantage. The rebuild in Phase 2 is where you decide whether you're a real AI-native app or a relabeled bolt-on, and it's worth doing slowly and well on one workflow rather than badly across ten. Phase 3 never ends, and it's the phase most engineering-led founders neglect because it isn't building. If you're going to be uncomfortable somewhere, be uncomfortable in Phase 3, because that's where the durable value actually is. This is the kind of sequencing I work through directly when advising app founders on what to prioritize.

One more thing I'd tell any founder reading this. The instinct, when a powerful new tool drops, is to go quiet and build. Resist it. The right move is to spend more time with merchants, not less, because the Toolkit just made understanding the problem the scarce skill and building the solution the cheap one. The founders who pull ahead in 2026 won't be the ones who built the most. They'll be the ones who understood their merchants best and pointed cheap, fast building at exactly the right problem. The tooling is the easy part now. Knowing what to point it at is the whole job.

The AI Toolkit and the Dev MCP are genuinely a big deal, and the 40-60% time savings is real. But the story isn't "building got easier." It's "building stopped being the thing that matters." When an agent can scaffold an app, wire the GraphQL, generate the UI extensions, and validate against the live schema, the build is no longer a moat, and the advantage moves to distribution into a 13,000-app store, proprietary data that compounds, workflow depth that resists removal, and merchant trust earned over years. Meanwhile demand moved too: AI-driven traffic to US retail grew 393 percent, AI-referred Shopify orders grew 13x, and the apps worth building are the ones pointed at that surface, not the old human-clicks funnel. The founders who win the next two years are the ones who take the time the Toolkit gives back and spend it on the things that stay hard.

If you're building an app and trying to figure out where your real, durable advantage sits now that the build is cheap, that's the conversation I have with founders constantly, as someone who's been the employee, the partner, the merchant, and the founder with an exit. The consumer SaaS practice exists for exactly this, and the app economics in one chart is a good place to see why the durable number is retention, not feature count.

Questions from
founders building in
the new workflow.