What people say about heal.
Teams that ran heal on their own code, in their words.
Twenty@twentycrmOur friends at @healdevHQ ran their tool on Twenty and found bugs our code review missed. Reviewing the friendship but recommending the tool.
Sep 24, 202616view on x
Florian Bienefelt@FBienefeltShoutout to @healdevHQ for creating a super strong bug hunter I can just run on our entire product, and output a list of issues with clear reproductions, recordings, ready for me to hand to my own agents. Running this weekly now to fight bugs and slop.
Oct 8, 20261view on x
Mark Ridgeon@RidgeonM@healdevHQ is a game-changer. Instead of just reading your code, it learns how to run your app and uses that runtime to catch and verify deep bugs/vulns. Big thumbs up!
Oct 7, 20260view on x
See heal run on open-source repos.
Heal built a production-like environment for each repo and uses it to find and validate reproducible defects.
Sandbox your app and find runtime issues
Heal learns how to run your environment. Finds defects. Validates them against the runtime. The best of static analysis, validated dynamically.
Reads your code, maps your architecture.
- checkout6 screensroutes/checkout.tsx:44
- billing4 screensfeatures/billing/plans.tsx:12
- search3 screensfeatures/search/index.ts:8
- onboarding5 screensroutes/start/[step].tsx:21
- account4 screensroutes/account.tsx:30
- admin7 screensapps/admin/src/main.tsx:5
What E2E tests and scanners miss
Untested integrations, edge cases, services disabled in staging, hard-to-mock async services. And everything where you need a runtime.
Heal runs these, on the sandbox:
- schemathesis
- ZAP
- dalfox
- jwt_tool
- nuclei
- semgrep
- trufflehog
- sqlmap
- and more…
| Trying to catch… | Legacy methods | heal |
|---|---|---|
| Edge cases | E2E runs the happy path against staging. Requests that fail, slow down or come back with a field missing are never staged. | Walks every flow again with the world failing, and files the screen that says “nothing here” when the server broke. |
| Services turned off in staging | Payments, mail and third-party calls are switched off. | Mocks them in a production-like sandbox, so the flows behind them run for real. |
| Validated runtime security issues | A static scanner reports a pattern in code that may never be reachable, and cannot tell you if it is. | Fires the real exploit at the sandbox, signed in as two people, and reports only what a test reproduces. |
| Missing routes | Dead pages, assets that do not load and screens no feature names are nobody’s test. | Crawls every link once, over the whole running app. |
Edge cases
E2E runs the happy path against staging. Requests that fail, slow down or come back with a field missing are never staged.
Walks every flow again with the world failing, and files the screen that says “nothing here” when the server broke.
Services turned off in staging
Payments, mail and third-party calls are switched off.
Mocks them in a production-like sandbox, so the flows behind them run for real.
Validated runtime security issues
A static scanner reports a pattern in code that may never be reachable, and cannot tell you if it is.
Fires the real exploit at the sandbox, signed in as two people, and reports only what a test reproduces.
Missing routes
Dead pages, assets that do not load and screens no feature names are nobody’s test.
Crawls every link once, over the whole running app.
Every defect comes with the test that proves it
What you get, what you should get, the screen it failed on, how it happens, where to look in the code — and the failing test that reproduces it.
Point it at your repo.
Connect GitHub and get your report. It runs locally or in the cloud.
Free trial · no credit card required