How to pentest your web app before launch (without hiring a firm)

You're days from launch. The landing page is sharp, signups work, the demo flows. Security is the thing you'll "do properly later."

Later is usually after the first stranger pokes at your signup form, your password reset, or that endpoint that returns a little too much JSON. The cheapest time to find those problems is before anyone's real data is behind them. Here's how to run a genuine pre-launch security pass on your own app — what a pentest actually checks, how to do it in an afternoon instead of a quarter, and how to read and fix what it finds.

"Security later" is a bet you'll lose

Most early breaches aren't exotic. They're the same handful of mistakes: a form that trusts its input, an ID you can change in the URL to read someone else's data, a secret committed to the repo, a server that will fetch any URL you hand it. None of these need a nation-state — just someone curious with your public URL.

Founders skip the check because the traditional option is genuinely painful.

The old way: €18,000 and a six-week wait

A traditional penetration test means scoping calls, a statement of work, a queue for a consultant, a week or two of testing, and a PDF a month later — often €15,000–€20,000 for one app at one point in time. Need a re-test after you fix things? That's another engagement.

For a funded company at compliance time, fine. For a founder trying to launch this month, it's a non-starter — so the check just doesn't happen.

What a real pentest actually checks (not a checklist scanner)

There's a difference between a scanner that flags a missing header and a pentest that actually tries to get in. A real pre-launch pass should probe the classes of issue that cause real breaches:

• Injection — SQL, command, and similar: does any input reach a database or a shell?
• Broken access control / IDOR — can one user reach another's data by changing an ID?
• Authentication flaws — session handling, JWT mistakes, password reset, default credentials.
• XSS and CSRF — can an attacker run script in someone else's session?
• SSRF and cloud metadata — can the server be tricked into fetching internal URLs or cloud credentials?
• Secrets and misconfiguration — exposed .env files, open buckets, debug endpoints, leaky error pages.

These map to the OWASP Top 10 and CWE classes for a reason: that's where the breaches actually are.

Step 1 — Authorize your target

A pentest is something you run against systems you own or have explicit permission to test — your own staging or production app, your own API, your own domain. Kalit Pentest is built around that rule: authorized targets only, and non-destructive by design. It proves a vulnerability exists without deleting your data or knocking the app over.

So the first step is simply: pick the app you're about to launch, and confirm it's yours to test.

Step 2 — Let it run recon, then exploitation

A real engagement isn't one scan; it's a sequence. Kalit Pentest runs it as a pipeline: it discovers what's actually exposed, fingerprints the technology and any web application firewall in front of it, maps the attack surface, and only then brings in specialists.

That last step is where the multi-agent approach earns its keep: around a dozen specialist agents work in parallel, each an expert in one area — one hunting injection, one chasing SSRF and cloud metadata, one testing access control, one probing authentication — sharing what they find as they go. It's the structure of a real testing team, running in minutes instead of weeks.

You don't drive any of it. You start the scan and watch the findings arrive.

Step 3 — Read the findings: evidence and the fix

A finding you can't act on is noise. Each result comes with three things that make it useful:

• Severity — a CVSS score, so you know what to fix first.
• Evidence — the actual request and response that proves it, not a vague "possible issue." You can reproduce it.
• Remediation — what to change to close it.

That last part is the difference between a report that scares you and one that helps you. The goal isn't a scary number; it's a short, prioritized list of concrete fixes.

Step 4 — Put it in your pipeline and re-test

Security isn't a one-time gate, because every deploy can introduce a new issue. Findings export as SARIF — the standard format GitHub and CI tools understand — so results can appear as code-scanning alerts in your repo, not just a PDF someone files away. You also get readable PDF and HTML reports to share with a customer or an investor running diligence.

Because a re-scan is just another run, "fix and verify" becomes a loop you close the same day — not a second engagement you have to book.

When to run it

At minimum: before you launch. In practice, also before a big traffic push, after you ship a major feature (new auth, payments, file uploads, an API), and before any security questionnaire or due-diligence review. Each of those changes your attack surface, and each is cheaper to check than to clean up.

The pre-launch security pass, summarized

1. Accept that the cheap time to find issues is before launch, not after.
2. Know what a real check covers: injection, access control, auth, XSS, SSRF, secrets.
3. Point an authorized, non-destructive scan at your own app.
4. Let it run recon → exploitation with a team of specialist agents.
5. Triage by severity, using the evidence and remediation in each finding.
6. Export SARIF into your pipeline and re-scan after you fix.

You don't need a five-figure budget or a six-week calendar slot to launch without an obvious hole in it. You need one honest pass over your own app before the first stranger takes theirs.