Why we run threat modelling before the first line of code

Most teams treat security review as something that happens near the end of a project: a checklist run against a system that already exists, mostly in the hope that nothing serious turns up. We run it the other way around: threat modelling is one of the first things we do, usually before a single component is chosen.

The reasoning is simple. A flaw found in a diagram costs a conversation and a redraw. The same flaw found in a staging environment costs a sprint. Found in production, after real users and real data are involved, it can cost a quarter, and sometimes a customer's trust that never fully comes back.

Finding a design flaw in a diagram costs an afternoon. Finding it in production costs a quarter.

In practice, this means asking uncomfortable questions early: what happens if this service is compromised, what does an attacker gain from this data model, which trust boundary is doing more work than it looks like it is. None of this requires exotic tooling: a whiteboard and a structured walkthrough of the architecture is usually enough to surface the decisions worth revisiting before they're expensive to change.

We run this exercise on every engagement, including internal tools that will never face the public internet. The habit is the point: security stops being a gate you pass through and becomes a question you keep asking, the same way you keep asking whether the system will still make sense in a year.