The idea of doing a little work up front to save yourself trouble later on is good in theory, but the reality of the early stage startup world is if you don't move fast enough you won't be around to experience that trouble later on. Sometimes it makes sense, sometimes it doesn't. The trick is to find a happy medium that works for your situation.

Totally agree on that last part. The pain rapidly diminishes as you come up with simpler ways to do things in a reusable way. Also, the tools to do it are getting better and better as more and more people are feeling the same pain.

Not only that, but it reduces the number of pivots you're able to try as a startup that is seeking product-market fit.

There's a massive difference between having procedure up-front (staging, etc.) and just writing correct code.

For instance, properly escaping output, parameterized queries, password hashing -- all those don't require more work (or if they do, it's so, so minimal). I mean, jeez, you're writing the code, just do it right.

That's a far cry from setting up multiple servers, certificates, etc. and having a real operations process. I can forgive, say, not having automatic builds. But there's no excuse for having a SQL injection in 2012.

You're right and I agree. I just meant one may as well try and do it all properly from the outset since it really isn't all that hard/inconvenient and imho the pay-off is worth it. If you want to build a secure system part of that is putting some planning effort in to your architecture and dev process before you breakout your text editor and start coding like a maniac. If you're a one man band, it doesn't have to be too OTT. Make the dev and staging boxes virtual machines on your desktop, create a *.mytestdomain.internal self signed cert that works on a dummy internal domain, use Trello as a bug tracker, keep a list of who has access to what and why on Goodle docs, subscribe to a few key security and vendor mailing lists, write a simple bash or Fabric script to deploy your site, keep sensitive project related login codes in a truecrypt container on a USB pen drive etc. Simple stuff but it all helps.

That may work for clearly defined product and very loose development timeline, but what when you need to make a social network based app with deadline 3 days from order, which may well be spiraling virally the day of the launch? Your security is then clearly post scriptum.

Disclaiming though, I clearly state to such clients that security will not be really up to challenge on those timelines. They usually don't care, even to a point that I don't really bother anyone with it, since I get blank stares when I discuss security with them.

> I get blank stares when I discuss security with them.

I can assure you that the blank stares go away completely when there is a breach. You will probably learn by then that your customers just expect you to handle it professionally. They might not be able to think beyond their deadline and their first business goal, but leaking passwords or losing user data will be your fault eventually.

I will not pretend that all my past work is bulletproof, but it should be not so difficult to make sure your tools and code handle all incoming data like hot grenades. You might skip some big-upfront-user-import in the beginning as you control the data chain, but $_POST or params[:model] or what else is flying in your face should be met with a standard treatment.

Think of it this way: right now you do not want to have your CV say "2012: developed user login module for LinkedIn. Finished within the deadline"

I suppose some apps will be different but a lot share the same basic security concerns. So just figure it out once and apply the best practices you've come up with to all future projects as a matter of course. It takes time to initially figure it all out but after that there's not too much extra effort required to code securely VS just smashing stuff together to meet a deadline.