You Just Raised Your Pre-Seed. Here's What to Do About Security.

You just closed your pre-seed. You have a small team, a product that kind of works, and 12 to 18 months of runway to figure out product-market fit. Security is not the first thing on your mind. It shouldn't be. But ignoring it entirely is how startups end up with expensive problems six months from now.

This isn't about building a security program. You don't have the headcount or the budget for that, and you won't for a while. This is about the minimum set of things that keep you from getting breached, getting blocked by a customer, or getting a nasty surprise during your next raise.

The reality of pre-seed security

At the pre-seed stage, you're probably two to five people. Your "infrastructure" is a Vercel deployment, a Supabase or Firebase database, and a Stripe integration. Maybe a handful of AWS services. Your code was written fast, possibly with AI tools, and it works well enough to demo and onboard early users.

None of that is wrong. Speed matters at this stage more than anything else. But speed creates specific risks, and those risks compound the longer they sit unaddressed. The auth system you scaffolded in a weekend doesn't get more secure as you add features on top of it. The API key you hardcoded during a hackathon doesn't become less exposed over time.

The good news: the security work that matters at this stage is almost entirely free and takes less time than you think. Most of it is configuration and hygiene, not engineering.

Week one: the non-negotiables

These are the things that should happen in the first week after your raise. Not because investors care (they probably won't ask yet), but because each one prevents a category of incident that could end your company before it starts.

Enable MFA everywhere

Turn on multi-factor authentication on every account that touches your product or your data. That means your GitHub org, your cloud provider (AWS, GCP, Vercel), your email (Google Workspace or Microsoft 365), your Slack, your Stripe dashboard, and your database provider.

This is not optional. Credential stuffing attacks target startups specifically because early-stage teams reuse passwords and skip MFA. A single compromised GitHub account with push access to your main branch is a full supply chain attack. The entire setup takes 30 minutes across all accounts.

Run a secrets scan

Install TruffleHog or GitLeaks and run it against your repository. These tools scan your entire git history for API keys, database credentials, tokens, and other secrets that were committed at any point, even if they've since been removed from the current codebase.

If you're building with AI tools like Lovable, Cursor, or Claude, this is especially important. Our research on AI-built apps found hardcoded secrets in nearly a third of the applications we reviewed. The AI generates working integrations but frequently skips the step of moving credentials to environment variables.

Any secrets found in your git history should be rotated immediately. Removing them from the code isn't enough because the old values still exist in previous commits.

Lock down your database

If you're on Supabase, verify that Row Level Security is enabled on every table and that your policies actually restrict access appropriately. If you're on Firebase, review your Firestore security rules. If you're on a managed Postgres or MySQL instance, confirm it's not publicly accessible.

This is the single most common critical vulnerability in early-stage startups. A misconfigured database with public exposure means anyone who discovers your API endpoint can read, modify, or delete your entire dataset. We've seen this in production apps handling financial data, health data, and PII.

First month: building the foundation

Once the immediate risks are addressed, you can start building habits that scale. None of these require a security hire. They require someone on the team (usually a technical cofounder) to own them.

Set up basic logging

You need to be able to answer the question "what happened?" when something goes wrong. At minimum, log authentication events (successful and failed logins), API errors, and database access patterns. Most cloud providers include basic logging for free. Turn it on.

You don't need a SIEM or a log aggregation platform at this stage. You need logs that exist and are accessible so that if a user reports something strange or you notice unexpected behavior, you can actually investigate.

Establish an access model

Who can access what? At two people, the answer is "everyone accesses everything." That's fine. But document it, and start thinking about what changes when you add person three, four, and five.

The practical version of this: use separate AWS/GCP accounts for production and development. Don't give every team member admin access to production. Use GitHub's branch protection to require reviews on the main branch. Set up a shared password manager (1Password or Bitwarden) and stop sharing credentials over Slack.

Write a one-page incident response plan

You don't need a 50-page runbook. You need a document that answers four questions:

1. Who do we contact first? (Internally and externally, including legal if you have a lawyer.)
2. How do we contain the issue? (Can you disable an API key, take a service offline, revoke access?)
3. How do we notify affected users? (Template email, timeline commitments.)
4. How do we prevent it from happening again? (Post-incident review process.)

Having this document before you need it is the difference between a measured response and a panicked scramble at 2 AM. It takes an hour to write.

First quarter: positioning for growth

By the time you're three months post-raise, you should be thinking about the things that will gate your growth over the next 12 months. These aren't urgent, but they take time, and starting now means you're not scrambling later.

Get a lightweight security assessment

A targeted security review at this stage gives you two things: a clear picture of your actual risk, and a remediation list you can work through over the next few months. This doesn't have to be a full penetration test. A focused review of your auth system, API endpoints, database configuration, and secrets management covers the areas where critical vulnerabilities live.

The report from this assessment also becomes an asset. When your first enterprise prospect sends a security questionnaire, or when a Series A investor asks about your security posture, you have something concrete to point to.

Start your compliance timeline

If you're selling B2B SaaS, you will eventually need SOC 2 or ISO 27001 certification. You don't need to start the audit process now, but you should know which framework your target customers require (see our comparison of SOC 2 vs ISO 27001) and start implementing the controls that overlap with good security practice.

The overlap is significant. MFA, access controls, logging, encryption, incident response planning: these are all compliance requirements that also happen to be the security basics we've already discussed. If you're doing the work in this article, you're already building toward compliance readiness.

Make security someone's responsibility

This doesn't mean hiring a security person. It means explicitly assigning ownership. Someone on the team needs to be the person who reviews access when someone leaves, who checks for dependency vulnerabilities periodically, who responds when a security researcher emails your team.

At most pre-seed startups, this is the CTO or a senior engineer. That's fine. It just needs to be explicit rather than assumed.

A realistic security timeline

What this actually costs

The security work described in this article costs almost nothing at the pre-seed stage. MFA is free. Secrets scanners are open source. Database configuration is part of your existing setup. A password manager runs $3-5 per user per month.

The first real cost comes at month three when you get a security assessment. Targeted reviews for early-stage startups start around $2,500 to $5,000, depending on scope. That's a fraction of what a breach costs (IBM puts the average at $3.31 million for companies under 500 employees) and a fraction of what it costs to do this work retroactively after you've accumulated a year of technical debt.

Compliance tooling (Vanta, Drata, Secureframe) runs $10,000 to $25,000 per year. That's typically a post-seed or Series A expense. But knowing your timeline and choosing your tool early means you're not rushed into a decision when the first enterprise deal depends on it.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.