Threat modeling has a reputation for heavyweight diagrams and daylong workshops. It doesn't have to. A focused afternoon with the right four questions catches most of what matters.
Draw the system as it really is: users, services, data stores, and the trust boundaries between them. Those boundaries are where the interesting risks live — anywhere data crosses from something you control to something you don't.
Then walk the four questions: what are we building, what can go wrong, what are we going to do about it, and did we do a good job? STRIDE — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege — is a handy prompt for the second one.
Write findings down as concrete, assignable tickets, ranked by impact times likelihood. A threat model that lives in a slide deck changes nothing; one that turns into three prioritised issues in the backlog changes the product.
Do it early, when a mitigation is a design tweak instead of a rewrite, and repeat it whenever the architecture shifts. An afternoon a quarter buys a lot of incidents that never happen.