[jasonkester]

There's no reason for security to slow you down when building version one of a product.

Application-level stuff like enforcing that User A can't modify User B's data takes no time to implement, and should flow out into the IDE as fast as the actual code for the feature if you keep it in the front of your mind. It just wouldn't feel right to write the IF block that checks whether a record exists without also checking that its userID matches up with the current logged in user.

Similarly, database constraints all go in at design time. The schema isn't ready until bad data won't fit. No extra time needed there either.

Beyond that, you're into stack and infrastructure security stuff. Pick your platform well and you get most of it for free. Good luck trying to author a SQL Injection bug in a compiled language with parameterized queries, for instance.

Really, it's all about having built things in the past, knowing what sort of issues need worrying about, and getting into a habit of never half-assing things. If you do that, you have to go out of your way to mess things up. It'll feel so wrong to cut corners that it'll probably actually slow you down to do so.

[spacemanmatt]

Upboats and agreement: Picking good infrastructure that you know you can handily win the security war with is key. It almost doesn't matter how secure your MVP is, if your architecture is securable. You can't bolt on a secure architecture after the fact but you can tighten the one you build in.