A security review before launch, not after

A security review costs money and slows a launch down. Both are true whether you do it before launch or after, and only one of them also works.

Why before

You can still fix it. A finding on a system in development is a ticket. The same finding on a live system with customers, an audit trail and a compliance obligation is an incident, a disclosure conversation, and a rebuild of whatever depended on it.

You can fix it properly. Knowing you have a problem before launch means you can change the design. After launch you can only patch around it, and patch around a structural problem is usually how it comes back.

Nobody has to be told. The most expensive part of a finding is rarely the fix. It is the hour spent deciding who to tell.

What we actually review

Against OWASP ASVS, which is a checklist somebody can agree with. "We do security" is not reviewable; "we test these eleven things before launch" is.

Authentication and session handling. Token lifetimes, refresh rotation, whether sessions are invalidated on password change, whether the reset flow leaks whether an account exists.

Authorisation on every route. The one that matters most and the one most often missing. It is not enough for an endpoint to check that a user is logged in; it has to check that this user may act on this record. We test that by logging in as different roles and trying to reach things we should not.

Input handling at the trust boundary. Everything crossing into the system from the client — including the fields your own front end validates, because the API does not know who called it.

Secrets. Not scanning for "password" in strings. Finding every credential that has ever been committed, every key in a client bundle, and every default that shipped and was never rotated.

What is logged. Logs are the least-reviewed part of most systems and they contain everything: tokens, personal data, and occasionally the answer to the question you are investigating.

What we do not do

We do not run an automated scanner and send you the output. Scanners find the same things every time and cannot tell you which of them anyone can reach.

We also do not hand over a PDF and disappear. A finding nobody can reproduce is a finding nobody will fix, so every one comes with the request that demonstrates it, and we retest after the fix to confirm it is closed.

That is why our security page lists OWASP ASVS and a retest as the deliverable rather than "a security report".

The awkward part

The review usually finds things the team already knew about and did not have time for. That is not a criticism of the team; it is what happens when a deadline is real and the security work is the part that can be deferred indefinitely because nobody can see it.

The useful question is not "how do we avoid this" but "which of these do we fix before launch and which do we schedule". We will help you answer that, and we will tell you if something is genuinely low risk in your specific context rather than applying the same severity to everything.

What we are not

We are not auditors. We do not issue SOC 2 or ISO 27001 certification, and we would be misleading you if a tool implied otherwise. We build to the standard, find the gaps, and prepare the evidence so you are not scrambling when a procurement questionnaire asks. An accredited body does the certification, and only after an audit.