Security is a design decision, not a final check

There’s a moment in a lot of projects where someone schedules a security review, usually a few weeks before launch. The reviewer is good. The findings are correct. And almost every one of them is expensive, because the architecture is already set and each fix means moving a wall.

Roles got bolted on as features shipped, so permissions are a tangle nobody fully understands. Secrets live in three different places. The audit log records some things and not others, because logging was never designed, it just accreted. None of this was anyone’s mistake exactly. It’s what happens when security is the last item on the list instead of part of the foundation.

Cheap early, brutal late

The cost of a security decision follows the same curve as any architectural decision. Made on day one, changing how access works is a conversation and an afternoon. Made after launch, it’s a migration, a regression risk, and a feature freeze while you sort it out.

So the useful question isn’t “is this secure,” asked at the end. It’s “how should access, accountability, and trust work here,” asked at the start, in the same meeting where you’re deciding the data model. Those decisions are entangled anyway. Pretending they’re separate is what makes the late fix so painful.

What “designed in” actually means

A few concrete things we settle early:

The roles model gets drawn before the first protected feature exists, mapped to how the organisation actually grants access rather than to whatever was convenient to code.

The audit log gets a schema, not just a few scattered console.log lines. If you can’t answer “who changed this and when” months later, the log isn’t doing its job.

Secrets get a home and a rotation story from the beginning, so they never end up pasted into a config file someone forgets about.

And we write a short threat model: what’s worth protecting here, and who would want it. It doesn’t need to be a hundred pages. It needs to point effort at the real risk instead of spreading it evenly over imaginary ones.

The quiet benefit

Designing security in doesn’t just lower risk. It tends to produce a cleaner product. A clear roles model makes the whole permission system simpler to reason about. A real audit log gives you debugging and support superpowers you didn’t expect. The discipline that keeps you safe is usually the same discipline that keeps the codebase sane.

That’s why we don’t treat it as a separate engagement. It’s part of how the thing gets built, decided while the product is still soft enough to shape.