A subscriptions app that reacts to Shopify rather than racing it.

Because the ones that exist mostly optimise for signing customers up, and the money in subscriptions is almost entirely in keeping them. We wanted the retention machinery, payment recovery, save flows and churn signals, to be the product rather than an upsell tier bolted on later.

You do not own the schedule. Shopify owns the subscription contract and the billing attempts, and your app reacts to them. That inverts the usual design: the app is a state machine responding to Shopify's billing events, not a cron job deciding when to charge. Getting that boundary wrong is the single most common source of duplicate charges in subscription apps.

Every retry is keyed to Shopify's billing attempt, not to our own timer, and each attempt is idempotent against that key. If our worker restarts mid-cycle it re-reads state from Shopify rather than assuming what it did last. The rule we hold to is that the app must be safe to run twice on the same event.

It is a signed, single-use magic link with a short expiry, scoped to one subscription contract. There is no account to breach because there is no credential to steal, and a leaked link expires. The trade-off is that the link must be re-requested rather than bookmarked, which is the correct trade for a page a customer visits a few times a year.

For merchants already on new customer accounts we do. But requiring an account creates a login step in front of a customer who wants to skip one delivery, and that step is where cancellations happen instead. The magic link exists to remove a decision point, not to avoid building auth.

It scores from the store's own order and engagement history rather than a global model, because subscription behaviour in coffee looks nothing like subscription behaviour in supplements. A shared model would be confidently wrong for most stores. The cost is that a new store needs some history before the scores mean anything, and we say so in the app rather than showing a made-up number.

No, and that was a deliberate constraint. It drafts save offers and clusters cancellation reasons, and a human approves before anything is sent. An AI that emails your customers unsupervised is a brand risk we were not willing to ship, for our own product or a client's.

It exposes subscription operations to AI assistants, so a merchant can ask ChatGPT, Claude or Copilot to look up a subscriber or move a delivery date. The engineering interest is in scoping: the assistant gets narrowly-scoped read and write access rather than a general admin token, because a broad token behind a chat interface is a liability.

Yes, and this is the point of the page. If your problem involves recurring billing, a customer-facing self-service surface, or a workflow where an automated decision needs human approval before it reaches a customer, the architecture here transfers directly.

Yes. A public App Store listing forces a higher bar on OAuth, webhooks, billing and privacy, so we build private apps to the same standard whether or not they are ever listed. The listing is a forcing function, not the goal.

A focused app with a defined scope is typically 8 to 16 weeks to a first public release. Subscriptions sits at the longer end because the billing edge cases and the recovery flows carry real money and cannot be shipped half-done.

It is yours. The app transfers to your Partner account, the repository comes with its history, and there is no licence fee to keep running it. We do not resell a client's custom build to the next client.

Yes, including the parts that surprise people: mandatory privacy webhooks, billing that survives an audit, and listing assets that meet the image and wording rules. We have been through it repeatedly and know where submissions get sent back.

Yes. Taking over an app someone else built is common, and it starts with a read-only audit of what actually exists rather than what the previous team documented. You get that assessment in writing before any remediation is quoted.

Then say so and we will look at it before proposing anything. If the honest answer is that your current app is fine and the problem is configuration, that is what we will tell you, even though it is worth less to us than a build.

Send the problem rather than the spec. What the business does, what is breaking, and what success would look like in numbers. You get a written response with a fixed-price range and a timeline, at no cost and with no obligation.