Explain My BuildWhat Explain My Build can and can't tell you
Last updated: August 30, 2026
Explain My Build reads your actual source code and retains evidence references for supported claims. It cannot infer intent that isn't in the code, it is not a live penetration test, and a human should review before publishing. When it can't verify something, it flags or refuses rather than guessing. For screen-only workflows or high-stakes fixes, other tools or a developer are the better call.
What can Explain My Build actually read?
It reads your real source code — the files, the configuration, the structure — and produces guides and a fix-list where supported claims retain evidence references. That's the foundation: unsupported conclusions are marked unknown, and available evidence can be inspected.
Concretely, from the code it can see and explain:
- What your app's features are and how they're wired together.
- How data flows and where it's stored (for example, a Supabase database and its tables).
- Configuration and environment variables the app expects.
- Access rules like row-level security as they're written in code.
- Dependencies and their versions — the raw material for a software bill of materials.
- Concrete, code-cited problems worth fixing — the code-verified fix-list.
Accessible source can inform the analysis, subject to parser and coverage limits. If it isn't, we don't pretend otherwise — which is the rest of this page.
What can't it infer?
It can't read intent that never made it into the code. Source tells you what the app does, not always what you meant, and there are things no static read can know:
- Your business rules that live only in your head. If a pricing rule or a policy isn't expressed in code or config, it can't be documented from code.
- Runtime-only behavior. How the app behaves under real load, with real user data, at 3am — that's observed, not read. Code shows the wiring, not the live current running through it.
- What's in external services you don't control. Settings inside a third-party dashboard that aren't reflected in your repo are invisible to a code read.
- Whether a design choice is right for your users. It can tell you what the code does; it can't tell you if that's what your customers actually need.
The core promise: Explain My Build marks unsupported conclusions as unknown
When Explain My Build can't verify a claim against your code, it flags it or leaves it out — it does not fill the gap with a plausible-sounding guess. A shorter, honest guide beats a longer, confident, wrong one. This is deliberate, but owner review is still required before publication or high-impact changes.
Is this a security test or a penetration test?
It is not an unrestricted penetration test or a security certification. Auger can coordinate available static, dependency and configuration checks and, only when explicitly authorised, bounded dynamic probes. Walker can observe selected journeys and access contexts.
Coverage is partitioned into automatically verified, manual-review and cannot-assess results. A clean result means only that completed checks found no matching issue; it does not prove the application or production environment is secure. Regulated or high-stakes systems still require qualified human review.
Does a human review before I publish?
Yes — you do, and you should. The guides and fix-list are drafts generated from your code, and they're meant to be reviewed by the person who knows the business before anything goes in front of real users.
This is a feature, not a caveat. Because the output cites its sources and flags what it couldn't verify, your review is fast: you're confirming and adding the human context (your business rules, your tone), not fact-checking a black box. The end-user guide especially benefits from your eyes — you know what your users actually get confused about.
We generate the honest draft. You add the judgment. That division of labor is the point.
When is another tool or a developer the better call?
Sometimes we're not the right tool, and saying so is part of being trustworthy. Reach for something else when:
| If you need… | Better call |
|---|---|
| A step-by-step of a workflow that isn't in code (a manual process, a spreadsheet routine) | A screen-recording tool like Scribe, Guidde, or Supademo |
| A guide for a no-code tool where you can't export the code | A screen-recording tool |
| A live penetration test or security sign-off on regulated data | A qualified security professional |
| Complex fixes where money, health, or legal data is at stake | A hired developer |
| Developer-facing API reference docs | A dev-doc tool (see end-user vs developer docs) |
Where we shine is turning your actual code into a founder runbook, a code-verified fix-list, and an end-user guide — honestly, with citations. Outside that, we'll point you to the right door.
Frequently asked questions
What are the limitations of Explain My Build?
It reads source code, so it can't infer business rules that live only in your head, runtime-only behavior, or settings inside external dashboards not reflected in your repo. It is not a live penetration test, and a human should review the output before publishing. When it can't verify a claim, it flags or omits it rather than guessing.
Is Explain My Build a security scanner or penetration test?
It can coordinate bounded code, dependency, configuration and authorised runtime checks, but it is not an unrestricted penetration test or certification. Unavailable dimensions are reported as cannot-assess, and high-stakes systems require qualified human review.
Does a human review the guides before they go live?
Yes — you review and approve before publishing. The guides and fix-list are code-generated drafts that cite their sources, so your review is fast: you add business context and confirm, rather than fact-checking a black box. The end-user guide especially benefits from your knowledge of where your users actually get confused.
When should I use a screen-recording tool instead of Explain My Build?
Use a screen-recording tool like Scribe, Guidde, or Supademo when the workflow you're documenting isn't in code — a manual process, a routine in a spreadsheet, or a no-code tool where you can't export source. Explain My Build derives from code; if there's no code to read, a recording is the better fit.
Why does Explain My Build refuse to guess?
Because a confident wrong answer is worse than an honest gap. When it can't verify a claim against your actual code, it flags it or leaves it out instead of inventing something plausible. That makes gaps easier to review; it does not make the output automatically safe to publish or act on — supported claims retain evidence references.
Turn your app into a guide your users can follow.
Start free with no credit card. Runtime varies with repository size, evidence sources and queue state.