Shipping your first Shopify app with Claude Code

An agency dev we’ve known for years sent us a Slack DM in May: “My first Shopify app just got approved. Built with Claude Code. Took roughly six weeks of nights and weekends.” Tomas builds client stores full time, so those six weeks were stolen hours after dinner. We’d shipped our own third internal app the same way two months earlier. Tomas pinged us, we compared notes, his timeline matched ours almost to the day.

The interesting part isn’t that AI can write a Shopify app. It’s where those six weeks actually went, because almost none of them went where he expected.

Scope one job, not a platform

Every failed first app we’ve seen died at the scoping stage, before a line of code existed. The builder sketches an all-in-one marketing suite, burns a month on auth and settings screens, and never ships the feature a merchant would pay for.

Tomas got this right. His app does one thing: it syncs inventory buffers across locations for merchants who oversell during flash drops. One problem, one settings page, one billing plan.

That’s the pattern we push on every client who brings us an app idea. Pick a job a merchant already pays a human or a spreadsheet to do, and do that job inside the admin where the merchant already works. A metafield bulk editor for a specific vertical beats a generic “store toolkit” every time. Niche utility apps with 200 paying installs quietly clear more than most venture-styled app businesses we’ve audited.

And Claude Code makes tight scoping more valuable, not less. The model is fast, so the temptation is to add surface area. Resist it. Every screen you add is a screen you’ll maintain through quarterly API version bumps for years.

The afternoon-one setup

The boring infrastructure that used to eat a week now takes an afternoon. Run the Shopify CLI scaffold, pick the Remix template, connect a dev store, and you have an embedded app running inside the admin with auth, session storage, and webhook registration already wired.

Point Claude Code at that fresh repo before you ask it for anything. Have it read the template structure, the existing routes, the webhook setup. The single biggest quality difference we’ve measured between our first AI-assisted app and our third is that we stopped letting the model invent patterns and started forcing it to extend the ones the template ships with.

Two practical setup notes from our own builds. Keep a dev store with realistic data, a thousand products and a few hundred fake orders, because an app that works on six test products falls over on real catalogs. And commit after every working increment. The model’s worst habit is confidently refactoring something that already worked.

Where the model actually saves the weeks

The honest accounting from our third internal app: 11 working days from scaffold to submission, part time. Our first hand-coded app in 2023 took two and a half months. And not by a small margin of effort either, the 2023 build had two of us on it.

The hours come back in specific places. GraphQL queries and mutations against the Admin API, which Claude Code writes correctly on the first pass most of the time if you paste in the schema types you care about. Polaris UI wiring, which is verbose and pattern-heavy, exactly what a model is good at. Webhook handlers, test fixtures, seed scripts. The repetitive 70% of app development that’s typing rather than thinking.

Where it doesn’t save time: decisions. Which API scopes to request, how to model your data when a merchant uninstalls and reinstalls, what happens when two staff members edit the same setting. We budget our review time at roughly half the generation time, and that ratio has held across three apps.

The embed: App Bridge, Polaris, and staying out of the iframe’s way

Your app lives inside the Shopify admin as an embedded iframe, and the platform has strong opinions about how that should feel. App Bridge handles session tokens, navigation, and toast notifications so the app behaves like part of the admin rather than a website wearing a costume.

The model handles this well with one caveat. Claude Code’s training data includes years of older Shopify app tutorials, cookie-based auth, REST-first patterns, deprecated App Bridge versions. When it reaches for one of those, the code looks plausible and fails review. Pin it to the current template patterns and the app design guidelines, and tell it explicitly which App Bridge version you’re on.

Polaris adherence sounds cosmetic. It isn’t. Reviewers flag non-standard UI, and merchants trust apps that look native. Use the components as shipped and bank the goodwill.

The server side nobody demos

Every Claude Code demo shows UI appearing like magic. None of them show the part that determines whether your app survives contact with a 40,000-SKU store.

GraphQL Admin API rate limiting is cost-based, not request-based, so a query that works in testing can throttle hard in production when a merchant’s catalog is 100x your dev store. Bulk operations exist for exactly this, and your app should reach for them on any job touching more than a few hundred records. We learned that one the embarrassing way on a client build, with a sync job that took 40 minutes on a real store and 11 seconds in dev.

Webhooks are the other quiet failure point. The mandatory compliance webhooks for customer data requests have to respond correctly or you fail review automatically. The app/uninstalled webhook has to actually clean up, billing state, stored tokens, scheduled jobs. Ask Claude Code to write uninstall cleanup explicitly. It won’t volunteer it.

Testing against the Built for Shopify bar

The Built for Shopify standard is technically optional, and treating it as the real bar is the cheapest marketing decision you can make. Apps that clear it get badging and better placement, and the criteria double as a pre-submission test plan.

Run the embedded pages through performance profiling on a throttled connection, because admin load budgets are real. Fresh-install the app on a clean dev store and walk the first five minutes like a merchant who’s never seen it, since that’s exactly what the reviewer does. Break your own onboarding before they do.

We keep a one-page checklist from the criteria and make the model walk it. Claude Code is genuinely good at auditing its own output against an explicit list, much better than it is at remembering unstated requirements.

The reject letter, pre-empted

App review in 2026 typically comes back in under a week, and the first-submission reject reasons are boringly consistent across every dev we’ve compared notes with.

Billing is the big one. If the test charge flow breaks, or the app gates features in ways the listing doesn’t disclose, you’re rejected. Wire the Billing API early and test the full subscribe, upgrade, cancel cycle on a dev store. The second cluster is the compliance webhooks above. The third is the fresh-install experience: apps that error before configuration, or demand scopes the core feature doesn’t justify. Reviewers read your scope list against your feature list, and so should you.

Tomas hit exactly one of these, an over-broad scope left over from an abandoned feature. He trimmed it, resubmitted, and cleared review in four days.

None of these rejections have anything to do with how the code was written. Nobody at Shopify asks whether an AI wrote it. They ask whether it works, bills honestly, and respects the data rules.

Pricing, maintenance, and what to hand-code yourself

Utility apps in this lane price between $9 and $29 a month, and the single-plan apps consistently outperform the three-tier pricing pages at this scale. Pick one price, one plan, and revisit after 100 installs.

Maintenance is the part nobody budgets. API versions release quarterly and supported versions roll off, so an unmaintained app starts dying within a year on autopilot. Budget a day per quarter minimum. Claude Code makes version migrations dramatically cheaper, paste the deprecation notices and let it propose the diff, but you still read every line.

Which brings up the rule we hold ourselves to: anything touching money or merchant data gets hand-reviewed at full attention, no matter who wrote it. Billing logic, auth, webhook verification, scope requests. The model drafts, you own, and that division of labor is pretty much the entire methodology.

What we keep telling clients

The six weeks Tomas spent weren’t spent writing code. By his own accounting, generation was maybe a fifth of the time. The rest went to scoping decisions, review, testing against real catalog sizes, and the submission checklist. That’s the honest shape of AI-assisted app development right now: the typing got cheap, the thinking didn’t.

For agency devs, this is the best margin story in years. An app that took a quarter of bench time now fits in the gaps between client work, which means ideas that never cleared the build-cost bar suddenly do.

For merchants and founders reading this with an app idea: the build cost collapsing means the moat was never the code. It’s distribution, the niche you understand, and the review-proof operational details above. Those were always the hard part, now they’re most of the part.

Tomas’s app crossed 60 paying installs in its first month at $14 a month. Not a business yet, but real money for nights and weekends, and his second app is already scoped. One job, one settings page, one plan. He learns fast.

Questions we get every week

Do I need to know React and the Shopify stack before trying this?

You need to read it, not write it from scratch. If you can review a Remix route and spot when a GraphQL mutation requests too much, Claude Code covers the production. Going in with zero web background means you can’t catch the model’s confident mistakes, and there will be some.

How long does Shopify app review actually take?

Days, not months. Recent first submissions we’ve tracked came back in three to seven business days, resubmissions after fixes were usually faster, and building your timeline around passing on the second attempt means you’ll rarely be disappointed.

Will Shopify reject an app because it was built with AI?

No. Review evaluates function, billing honesty, performance, and data compliance, not authorship. Every rejection we’ve seen had a concrete operational cause that existed before AI tooling did.

Public app or custom app for one client?

If one merchant is paying for it, ship it as a custom app first and skip review entirely. Take it public only when a third unrelated merchant asks for the same thing, because that’s the signal the niche is real.

Have an app idea your team can’t get to? Talk to us about a build sprint and we’ll scope it, ship it with the same Claude Code workflow we use on our own apps, and walk it through App Store review with you.