Why we built Ayra

I have been building on Shopify for over ten years, first as a developer, then as the person agencies call when the stack stops making sense. For the last few of those years, almost every engagement we took at Tetralogicx that had “retention” in the brief followed the same script. This post is about that script, and why we decided to stop running it by hand.

The audit we ran every time

A merchant would come to us with a reasonable goal: get more second orders. The first week was always an audit of what was already installed. The list rarely varied much. A loyalty app. A reviews app. A wishlist app, sometimes with back-in-stock bolted on. An email tool with its own flows. Often a subscriptions app. Occasionally a referral app that was separate from the loyalty app, even though both of them handed out rewards.

Each of these apps was good at its job. That was never the problem. The problem was that each one had built its own picture of the customer. Loyalty knew the points balance but not that the customer had left a one-star review last week. Reviews knew about the review but not that the customer was a VIP. The wishlist app knew what the customer wanted but had no idea a win-back discount was going out that afternoon.

Six apps, six partial customers. And at the end of the month, six dashboards, each attributing the same orders to itself.

The glue we kept writing

So we wrote glue. That was the engagement, really. Sync points balances into customer tags so the email tool could segment on them. Suppress review requests for anyone with an open support ticket, which meant polling the helpdesk and writing tags again. Delay the referral push if a discount had gone out in the last few days. Reconcile the revenue reports so the merchant could see one number instead of six.

Some of it was Shopify Flow. Some of it was small apps we hosted. All of it was fragile, because it sat between tools that did not know it existed. When a vendor changed a webhook payload, the glue broke. When the merchant’s team changed a flow in the email tool, the glue broke. And when we rolled off the project, nobody was left who understood it.

We did this enough times to notice two things. First, the glue was the same from store to store. The names of the apps changed; the logic did not. Second, every piece of it existed to compensate for one missing thing: a single customer record that all the retention logic could read from and write to.

The customer record has to come first

At some point the honest answer to “which app should we add next” stopped being an app name. The customer record has to come first. Loyalty, reviews, referrals, wishlist, subscriptions and flows are all things you do to a customer, based on what you know about that customer. If the knowledge is split six ways, the actions will collide.

That is the whole idea behind Ayra. One profile per customer, resolved across email, phone, customer ID and device. Every module writes its signals to that profile and reads from it before it acts. And in front of the shopper, one decision layer that looks at everything the modules want to do and picks the single next best action, which can be nothing at all. We call that layer Journey Guard, and it is the part we are most careful about, because it is the part that stops retention from turning into noise.

We wrote the whole model up on the how it works page, including the loop and a glossary of the guards. It is deliberately written to be read in a few minutes.

What is in the private beta

We are not launching everything at once, and we would rather be clear about the order than pretend.

Wishlist, back in stock, pre-order, reviews, subscriptions and lifecycle flows follow. The ones that come from products the team has already shipped, like our wishlist and back-in-stock work, will arrive faster than the ones we are building fresh.

What we are not claiming yet

A few things we want to be straight about, because the category is full of claims that do not survive contact with a real store.

The engine is rules, not a model. At launch, opportunity types, eligibility and scoring are explicit rules you can read. Every decision has a reason recorded in the customer timeline. We will layer prediction on top of this later: churn, repeat-purchase likelihood, best send time. We are building the decision infrastructure first because a prediction with nowhere to act is just a report.

We do not have lift numbers to show you. We have years of agency work that tells us where the collisions happen and what fixing them did for individual clients, but we are not going to turn that into a headline percentage. When beta merchants have run on Ayra long enough to measure, we will publish what we see, with the method.

Switching is not free, even when migration is. We import from the apps we replace, and migration is free during the beta. But moving a loyalty program is a customer-facing change and deserves a plan. Our comparison pages say where each app is genuinely better and when you should stay put, because we would rather lose a signup than a merchant’s trust.

Why an agency is building this

People ask whether an agency should be building a product. The honest answer is that this product only exists because of the agency. We did not guess at the problem; we were paid to solve it, badly, many times. The engineers building the loyalty and wallet pieces are the ones who shipped our order management and tracking products. The people building the storefront extensions built our wishlist app. Tetralogicx stays an agency, and Ayra is a product team inside it, funded by that work.

If you run a Shopify store and the “six apps, six records” story sounds familiar, the waitlist is at the bottom of this page. We are onboarding in small batches so that we can watch every store closely, and we would like one of them to be yours.