The runtime gap is the next frontier for seller-side tooling
Cross-border e-commerce operators have spent the last two years wiring AI into everything: listing generation, ad copy, customer service macros, even supplier negotiation. What most of us have not done is apply that same rigor to the software we actually run our stores on. A missed bug in a Shopify checkout extension, a broken webhook between your 3PL and your order management system, or a silent failure in a returns portal does not show up in a code review — it shows up as a chargeback, a late shipment, or a one-star review. That is why a recent launch from heal.dev caught my attention more than any listing-optimization tool this quarter. It is not an e-commerce product. But the problem it attacks — code that looks fine and fails in production — is the same problem quietly bleeding margin out of every DTC operation running custom tech.
What heal.dev actually solves, and why it is not another code reviewer
The pitch from maker Malo Marrec is straightforward: code review and static analysis miss real runtime bugs and vulnerabilities, and even top-performing coding agents still ship bugs to production. Instead of scanning source code, heal.dev spins up a production-like sandbox with external dependencies mocked, hunts for bugs, performance issues, and vulnerabilities at runtime, and reproduces each finding against that sandbox before reporting it. The output is fewer findings, but each one is tied to a proven user behavior that causes a real failure.
That distinction matters more than it sounds. The typical AI code reviewer — think the review bots bolted onto GitHub pull requests, or the static scanners that have been part of CI pipelines for a decade — finds what a developer would change to keep code clean. That produces a lot of findings, many of them stylistic or theoretical. Heal’s team frames the contrast bluntly: review bots find what a developer would change; Heal finds a proven user behavior that causes a bug. For an operator, that is the difference between a ticket you can ignore and a ticket that explains why checkout fails for Safari users on iOS 17.
The product is free during beta with no credit card required, per the launch page. That is a deliberate land-grab pricing move, and it tells you the team expects to monetize on volume or on team seats later — worth noting if you are evaluating it for a production dependency.
The benchmark claim, and how much weight to give it
Co-founder Pierre Oucif posted a benchmark claim in the comments: 70% of the defects Heal finds are not caught by any code reviewer, and stacking two or three reviewers does not close the gap because they overlap heavily on the same classes of bug and all miss the ones that only surface at runtime. The full methodology and defect list live at heal.dev/benchmark.
I would treat that 70% as directionally credible but vendor-sourced. The methodology is published, which is more than most launch-day benchmarks offer, but the defect corpus is presumably chosen by the team that built the tool. The honest read: the category gap is real — static analysis genuinely cannot see runtime state — but the exact percentage will move once independent testers run it against their own codebases. One commenter, Mark Ridgeon, reports running it against his own app and finding a stored XSS and a cross-tenant data leak among 239 findings, triaged in about an hour via the API. That is a useful data point because it is a third party describing specific bug classes, not a marketing number.
How it differs from the tools you are probably already paying for
If you run a Shopify store with any custom app, or an Amazon FBA brand with a proprietary repricing or inventory-sync layer, your current stack probably includes some combination of the following. It is worth being precise about where heal.dev sits relative to each.
Static analysis and linters — the SonarQube-class tools and the language-native linters — check code without executing it. They are cheap, fast, and catch a real class of problems, but they cannot see what happens when your cart logic meets a malformed webhook payload at 2 a.m. Heal’s entire thesis is that this gap is where the expensive bugs live.
AI code reviewers — the pull-request bots now bundled into most Git hosts — are trained to suggest changes a human reviewer would suggest. They are useful for consistency and style, weak on runtime behavior, and prone to volume. The stacking argument in the comments is the interesting one: if you have ever turned on two reviewers and watched them flag the same 40 lines, you already believe it.
End-to-end testing tools — the wave of AI-generated E2E suites — require you to define the happy path. Heal’s maker explicitly positions against this: unlike asking a coding agent to write end-to-end tests, Heal proactively hunts edge cases and runs exploratory testing rather than just the happy path. That is the sharpest differentiator in the whole launch, and it is also the hardest claim to verify without running it yourself.
Coding agents themselves — Claude, Codex, and the rest — write the code and, increasingly, write the tests. One commenter, Yvan Derogis, describes a flywheel: let Claude or Codex build, hand it to heal.dev to find what the agent missed, let the agent repair, then re-verify with heal.dev. He calls the looped result materially better than the agent alone. That is the workflow pattern I would actually copy, regardless of which tool you use.
Why Amazon sellers should care more than Shopify ones
This is counterintuitive, so let me make the case. A Shopify merchant with a stock theme and a handful of apps has relatively little custom code in the critical path — the platform absorbs most runtime risk. An Amazon FBA brand, by contrast, tends to accumulate a sprawl of custom glue: Seller Central API integrations, repricing logic, inventory sync between a 3PL and a forecasting sheet, review-monitoring scrapers, and increasingly a proprietary dashboard someone built in-house. That glue is exactly the kind of code that passes review and fails at runtime, and its failures are denominated in suppressed listings, oversold inventory, and account health dings. The blast radius per bug is higher on the Amazon side even though the codebase is smaller. If you are a marketplace account manager reading this, the question to ask your dev lead is not “do we have tests” but “when did we last reproduce a failure against a sandbox that mocks Seller Central’s responses.”
What cross-border operators can borrow from this launch
Even if you never touch heal.dev, three things in this launch are worth stealing for your own stack.
First, the sandbox-with-mocked-dependencies pattern. The reason most e-commerce integrations break is that staging environments do not mock the external services faithfully — the 3PL’s API returns a different error shape than the sandbox, the payment processor’s test mode behaves nothing like production, the marketplace API rate-limits differently. Heal’s insistence on mocking external dependencies and reproducing every finding before reporting it is a discipline your own engineering team should adopt for any integration in the order-to-cash path.
Second, the triage-by-API workflow. Ridgeon’s note that the API let him triage 239 findings in about an hour is the operational detail that matters. A security tool that produces findings faster than a human can triage them is a liability, not an asset. When you evaluate any monitoring or QA tool — including the ones inside your Shopify admin or your Amazon Seller Central stack — ask how the output gets into your existing ticketing flow, not just how good the detection is.
Third, the loop, not the tool. Derogis’s flywheel — agent builds, runtime tool finds, agent repairs, runtime tool verifies — is the correct mental model for AI-assisted development in 2025. The tool is replaceable; the loop is the asset. If you are running a small in-house dev team for a DTC brand, this is the workflow to standardize on before you standardize on any vendor.
Where the math breaks
Two honest caveats. First, the scope limitation the makers acknowledged in the comments: Heal hunts for issues in application code and does not run against installed libraries. When a commenter asked about the recent PHP interpreter CVEs, the team confirmed that library-level and language-runtime vulnerabilities are out of current scope, though they noted the memory-management angle is adjacent to what they do. If your stack’s risk is concentrated in third-party dependencies — which, for most e-commerce builds, it is — this tool does not cover that surface. You still need dependency scanning.
Second, the GitHub assumption. A commenter using AWS CodeCommit asked about local Git compatibility, and the team said a local version exists internally and is planned for release in a couple of months. Until then, if your repos live outside GitHub, you are waiting. That is a real adoption blocker for teams with mature, non-GitHub CI setups.
Where my judgment says it falls short
The launch is strong on thesis and thin on the things operators need before they bet a production dependency on it. Pricing beyond beta is not disclosed. The benchmark is vendor-run. The local-Git version is promised, not shipped. The MCP integration that would let a coding agent query Heal and auto-remediate findings is described by the maker as something they are “working on,” with speed and UX still being figured out — which means the autonomous loop everyone in the comments is excited about is, today, partly manual.
There is also a category risk the launch does not address: the AI code review vendors are not standing still, and the large coding-agent platforms have every incentive to absorb runtime verification into their own harnesses. Heal’s defensible position is the sandbox fidelity and the reproduction step — the part that is genuinely hard to build. If that holds, it is a real moat. If the incumbents bolt on a mock-dependency sandbox, the differentiation compresses fast.
For a cross-border operator, the practical translation is this: treat heal.dev as a high-signal supplement to your existing QA, not a replacement for dependency scanning, not a replacement for your Git host’s review flow, and not yet something to wire into an auto-merge pipeline. The maker’s own debate-club question — could Heal be the reason you finally auto-merge all PRs — is the right question to ask, and the honest answer today is “not yet, but the direction is correct.”
What I’d watch / test next
This week, if you run any custom code in your order-to-cash path, do three things. First, sign up for the free beta and point it at one non-critical repo — ideally your returns portal or your inventory-sync service, not checkout — and see whether the findings are reproducible and actionable or just noisy. Second, read the published benchmark methodology and decide for yourself whether the defect corpus is representative of your stack; if your bugs are mostly dependency CVEs, this tool is not the answer. Third, regardless of the tool, steal the loop: have your coding agent build, run a runtime verifier, have the agent repair, re-verify. Watch for two signals over the next quarter — the local-Git release the team promised in “a couple of months,” and whether the MCP integration ships well enough to make the autonomous remediation loop real. If both land, this moves from interesting to infrastructure. If neither does, it stays a useful point solution for GitHub-based teams with runtime-heavy custom code.
