What Explain My Build can and can't tell you

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 every claim points back to a specific place in that code. That's the foundation: nothing in the output is invented, and anything it states, it can show you the line for.

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.

If it's in the code, it's fair game. 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.

Is this a security test or a penetration test?

No. Explain My Build reads code; it does not attack your running app. It can spot problems that are visible in the code — for example, a row-level security rule that's clearly too loose, or a secret that appears to be committed where it shouldn't be. That's real and useful.

But it will not probe your live system, attempt exploits, test authentication flows against your running server, or simulate an attacker the way a penetration test does. It can flag a supply-chain risk that shows up in your dependencies; it cannot confirm your production environment is actually hardened.

If you handle sensitive data — payments, health, anything regulated — treat our code read as one input, not a clean bill of health. A real security review by a qualified human is a different and necessary thing. We'd rather tell you that plainly than let you over-trust a code read.

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:

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.