Most project plans we inherit have a line near the bottom that says "security review". It sits after launch prep and before handover, and it gets squeezed when the timeline slips. By the time anyone reads the code with an attacker's eye, the architecture is fixed and every finding turns into a rewrite.
We move that work to the start. It isn't heroic. It's cheaper.
The first week sets the defaults
The decisions that matter most for security happen before anyone writes a feature. On a new project we settle these in the first week:
- How users sign in. We pick the authentication library, the session model and the password or passkey policy up front. Swapping auth later touches every screen.
- Who can see what. We write down the roles and what each role can read and change. Broken access control sits at number one on the OWASP Top 10:2025, and most of those bugs come from permission checks someone added screen by screen.
- Where secrets live. API keys and database passwords go into a secrets manager or the host's environment settings on day one. They never enter the repository, even "for now".
- What gets logged. We decide which events go to the audit log (logins, permission changes, exports) so the log exists before the first incident.
None of this slows the project down. Each item takes an hour or two when the codebase is empty and days when it isn't.
Secure defaults in the code
We start new projects from a template with the dull protections already switched on:
- HTTP security headers, including a Content Security Policy we tighten as the app grows
- CSRF protection on every form
- Parameterised queries through the ORM, with raw SQL flagged in review
- Rate limits on login, password reset and any endpoint that sends email or SMS
- Dependency and secret scanning in the CI pipeline
A developer who wants to turn one of these off has to say why in the pull request. That one rule catches most of the shortcuts that turn into incidents later.
Review with a checklist, every sprint
Our code reviewers use a short security checklist on every pull request. It asks questions like: does this endpoint check the user's permission, or does it trust an ID from the URL? Does this upload handler check file type and size? Could this error message leak data?
Once a sprint, one engineer spends an afternoon reading the new code only for security. They don't review style or naming. They look for the things an attacker would try first. Findings go into the next sprint like any other bug.
Hardening before launch is a checklist, not a phase
Because the defaults are in place, the pre-launch pass takes days instead of weeks. We run an automated scan, check the server and cloud configuration against a baseline, confirm backups restore, and test the admin area with a non-admin account. Security misconfiguration is the second item on the OWASP list, and most of it lives in server settings that nobody looks at after the first deploy.
What this costs you
Security work spread across sprints is easier to plan and price than a rushed review at the end. A late security review that finds an access control flaw in a finished app can cost more than the feature it sits in. You also get something harder to price: the code you receive has been read for security all along, so the next team can extend it without re-auditing everything.
If you have an app that went live without this kind of pass, we can run the same checklist against it and give you a prioritised list of fixes.
Source: OWASP Top 10:2025.
