Security is one of those things you can't just toss in at the very end. In order to do it right, you really have to include security in your design from the ground up.
It seems like bullshit at first. The model of "secure software development" tends to culminate in notably different software designs. For instance, a proper payments service would have security at its forefront. A naive one might process all requests that come its way; OTOH, a secure payments service might choose to process only those requests that seem trustworthy (does the request look suspicious? does the requester have a history of abuse? etc.).
Security is something that will fundamentally shape the architecture and design of your system. You can't just go back and make these types of gigantic changes.
I guess it all comes down to whether you are willing to accrue technical debt by not designing securely from day 1. If you get funded, you can go back and change things, but (in practice) you can only change so much.
It seems like bullshit at first. The model of "secure software development" tends to culminate in notably different software designs. For instance, a proper payments service would have security at its forefront. A naive one might process all requests that come its way; OTOH, a secure payments service might choose to process only those requests that seem trustworthy (does the request look suspicious? does the requester have a history of abuse? etc.).
Security is something that will fundamentally shape the architecture and design of your system. You can't just go back and make these types of gigantic changes.
I guess it all comes down to whether you are willing to accrue technical debt by not designing securely from day 1. If you get funded, you can go back and change things, but (in practice) you can only change so much.