Where audits happen and why timing matters
Audits are typically scheduled to happen after a contract's core functionality is considered feature-complete but before it is deployed to a live network where it will hold real value, and that timing isn't arbitrary. Reviewing code before mainnet deployment means any vulnerability found can be fixed for free, in the sense that no user funds are at risk yet, no exploit has happened, and the fix is just a code change followed by, ideally, a follow-up review of the patched sections. Auditing too early, before the design has stabilized, wastes reviewer effort on logic that's likely to be rewritten anyway, while skipping an audit or auditing too late, after deployment, means any bug found is a live liability rather than a design flaw caught on paper. This is also why serious protocols increasingly treat a single audit not as a one-time gate to pass but as one checkpoint among several, often including an initial audit, a second review after major changes, and a final check immediately before launch.
This lifecycle placement also explains why reputable auditing firms insist on reviewing final, or near-final, code rather than an earlier draft. A protocol that gets audited, then makes substantive changes afterward to fix unrelated bugs, add features, or optimize gas, and deploys that changed code without a follow-up review has effectively deployed unaudited code while still holding an audit report that describes an earlier, different version. Understanding this is part of understanding what an audit actually purchases: it's not a property that attaches to a protocol's brand or team, it's a property that attaches to specific bytes of bytecode at a specific commit, and any divergence from that exact code falls outside what was actually reviewed.