How Canterr and Anthropic helped Atrox streamline Shopify mobile app development

One feature, three codebases, no room for drift

Almost every Atrox feature cuts across the stack. A new storefront block needs a definition and validation schema in the API, an entry in the block index, patch schemas, seed data, controls in the web builder and a renderer in the mobile app. A campaign popup needs a data model, a composer for the merchant and a renderer for the shopper. Each hand-off between repositories is a chance for the pieces to disagree.

Some of those disagreements only show up in production. The mobile app calls one set of routes in live preview and a near-identical set in a built APK. On August 4 a production route was missing the sort and filter parameters its preview twin accepted, so collection sorting worked in preview and silently did nothing in the shipped app. Bugs like that are invisible in development, and merchants find them first.

Atrox also had a long road between a working builder and a product merchants could rely on: a server-side build worker, per-store signing keys, branded launch icons and splash screens, over-the-air updates, crash reporting, billing and Shopify App Store compliance. With two engineers facing that whole list before a Shopify App Store launch, Atrox could not afford to build any of it slowly, or twice.

Plan in the repo, remember across sessions, build in parallel

Plans with a status board

Kartik Pavan, a software engineer at Atrox, works in Claude Code from the terminal, mostly with Claude Opus. Large features start with research: Claude maps what already exists across every repository and what is missing, then writes a numbered plan series into the repo, one document per pull-request-sized step. Before the design is locked, a /grill-me session has Claude question it until the open decisions are settled.

Each series has an overview with a status board: plan, repository, status and an estimate in days. When a step lands, the board records the date and how it was verified. The road-to-production series, for example, records that signing certificates stayed stable across builds and that a version upgrade installed over the old app on a real device. Plan series now cover production readiness, in-app messaging, push notifications, pricing, an admin dashboard, App Store launch and email delivery.

Memory that outlives the session

The API, mobile and marketing repositories each carry a CLAUDE.md with house rules, and Claude keeps a persistent project memory. It holds the things that are easy to forget and expensive to relearn. After the August 4 sorting bug, a note recorded the rule: when touching either the preview or the production controller, diff it against its twin. Others record how to wire a new builder block and what must run alongside a deploy.

Rules that must never slip are enforced in code, not just remembered. A Claude Code hook in the API repository checks every file Claude writes or edits against the project’s comment rules before the change is accepted. Project skills encode repeat work, including a Shopify App Store compliance review and React Native performance rules.

Sessions that talk to each other

For cross-cutting work, Atrox runs a Claude Code session in each repository and lets them coordinate directly. The API session defines the endpoints, then messages the builder and mobile sessions with the contract, so each side builds against the same shape. On August 3, in-app messaging landed this way: a campaign model and delivery API, a composer with a live device preview in the builder, and a popup renderer in the app that applies discount codes to the cart.

Advised by Canterr

Atrox brought in Canterr, an IT consulting firm, to advise on deploying Claude Code across its small engineering team. Canterr advised on best practices for working with Claude Code day to day and on agentic development more broadly, as the team moved to planning, delegating and verifying work with Claude.

“Atrox didn’t add a chatbot to its team. It gave its codebases a memory, a planning habit and a way for agents to work on the same feature at once.”

Days where the plan said weeks

The road-to-production series laid out ten steps to turn the builder’s “Generate APK” button into a signed, branded app a merchant could install and keep updating. Its own estimates came to about 8 days of focused work. Eight of the ten steps were done in three days, each checked on a real device before it was marked complete.

The pace held for features that touch every layer. In-app messaging, planned at close to a week across three repositories, was coded in a day. Order-status push notifications followed and were verified with a real test order on a phone. Billing went from plan to a live Shopify subscription test in under a week.

Less visible wins

Claude also took on work nobody schedules. It traced an oversized Android build to fonts and icon sets the app never used, added response caching to the preview API and sped up how the builder loads screens.

Atrox also prepared for Shopify App Store review, including privacy compliance webhooks and a project skill that checks the codebase against App Store requirements. In under three months, two engineers took Atrox from a working builder to a product merchants can pay for: signed and updatable apps, push notifications, in-app campaigns, support, billing and App Store compliance.

From builder to App Store

Atrox is preparing its Shopify App Store submission and its first production iOS builds. The same loop is already driving the next plan series: an eight-step email delivery plan, a production deploy runbook and the App Store listing kit.

The method carries forward too. Every new series starts the way the first did: research the gap, grill the design, write the plan, build in parallel, verify on a device, and write down what the next session needs to know.