when is the “right time” to think about smart contract security?

I get why teams postpone security until “audit time”, but that usually backfires.

Most audit cycles I’ve seen don’t get burned on some exotic exploit first — they get burned on basics the team could’ve settled before writing half the code: who has power, what happens if keys are compromised, whether upgrades are safe, what external calls can break assumptions, what the protocol thinks is always true (but never wrote as an invariant).

We do run checks before booking an audit, mainly because it saves money and reduces churn. Nothing fancy: a couple of automated scanners, some basic unit + invariant tests, and one human pass only on the scary surface area (roles/admin, upgradeability, external calls, accounting paths). 

If we can’t explain “who can do what” and “what can go wrong” in plain language internally, an auditor will spend the first week just untangling that.

On the AI pre-audit idea — useful if it’s positioned as “catch obvious risks + explain them clearly”, not as a replacement for audit judgment. The real value is: reducing repeated hygiene issues and helping founders/devs fix the same patterns earlier. But it has to be honest about confidence level, otherwise it becomes a false-safety machine.

If you share 2–3 example outputs (like: “this role can drain funds because X”, “upgrade path is unclear because Y”), people can tell you quickly whether it’s actually helpful or just noisy.