1
3 Comments

There's a Shopify permission almost no app has. We just got it.

Couple months ago we started building a growth agent that reads your PostHog analytics and your codebase, finds what's actually killing conversion, and proposes the fix.

Every tool like this stops at the report. You get a dashboard, a list of "insights," and then someone still has to find the file, write the fix, test it, ship it. We wanted ours to actually do the work.

So it doesn't just tell you your PDP has a scroll-depth problem or your checkout has a silent JS error killing mobile conversions. It opens the file, writes the fix, and sends a yes/no approval request on Telegram before anything ships. Approve, and it either opens a GitHub PR, or for Shopify stores, writes straight into your live theme.

That last part is the hard one. Shopify locks live theme writes behind a manual review called a Protected Scope Exemption, and most apps never get through it. We applied, went back and forth with their review team for weeks, and got approved last week. The full pipeline is live and verified end to end now: OAuth, theme picker, approval gate, confirmed writes on a real store.

If you run a Shopify store and conversion has been a persistent problem, there's a 14 day trial, no card required.

Happy to talk through the rollback safety design (checksum re-verification + partial batch tracking so a failed write can't brick a theme), or why we built a human approval gate instead of full autonomy.

on July 2, 2026
  1. 1

    Getting the Shopify permission is a strong technical milestone.But the trust question probably starts after that: will a store owner approve an AI-written change on a live theme?Rollback helps, but it may not be the whole trust mechanism.For Shopify, the first trust signal might be more like:can the merchant understand exactly what changed, why it changed, what page it affects, what the before/after looks like, and what happens if the numbers drop?A useful test could be to show 5 Shopify store owners one real proposed fix before asking them to install the full workflow.
    For each fix, show:

    • the conversion problem Velyr found
    • the data behind it
    • the page/theme area affected
    • the proposed change
    • a visual preview
    • the risk level
    • the rollback condition
      Then ask only one thing:
      “Would you approve this change?”
      If they say no, the interesting part is why.
      Maybe the fix is too broad.
      Maybe the evidence is not strong enough.
      Maybe they do not trust the metric.
      Maybe they need a preview, not just a rollback.
      Maybe they would approve PDP copy/layout changes but not checkout or theme logic.
      That probably tells you what the safety design needs to prove first.The hard part may not be getting permission to write to Shopify themes. It may be giving merchants enough confidence to say yes to one specific, bounded change.
    1. 1

      Really good point. That's actually one of the main reasons we chose a human approval gate instead of full autonomy.

      Before anything can be applied, the merchant sees the issue the Velyr agent found, the supporting analytics, the exact files that would change, a code diff, before/after screenshots, and the explanation of why the agent is proposing the change. If they don't like it, they simply don't approve it. And if they do approve it, every change is still reversible.

      We learned pretty early that "AI thinks this is better" isn't enough. The goal is to make every proposed change understandable, reviewable, and easy to verify before anything touches a live store.

      I like your idea of testing approval rates for individual proposals as well. "Would you approve this change?" is probably one of the best ways to measure whether we've earned enough trust.

      1. 1

        That makes a lot of sense.The approval gate matters, but the real trust seems to come from whether the merchant can verify the specific change before saying yes.Issue found, supporting analytics, exact files, diff, before/after screenshots, explanation, and rollback changes the question from:
        “Do I trust AI?”
        to:
        “Can I understand and approve this bounded change?”
        That feels like the right frame.
        The next useful signal may be approval behavior per proposal:
        which changes get approved quickly,
        which ones get rejected,
        and why.

        A rejection could be just as useful as an approval if it shows what trust evidence was missing: clearer preview, smaller diff, stronger metric, lower-risk page, or better rollback explanation.That would probably tell you more than asking merchants whether they generally trust AI-generated changes.Really like the direction of making every proposed change understandable, reviewable, and verifiable before it touches the store.