Pre-Seed checklist

Is there a consistent language and framework choice, or are multiple technologies used without clear rationale?

Technology fragmentation at pre-seed usually reflects experimentation. It becomes expensive when the team needs to hire.

Are large files or god functions doing many things at once, suggesting a lack of architectural thinking?

Monolithic functions that grow to handle everything are the earliest sign of future technical debt.

Are external dependencies pinned to specific versions, or are floating versions used?

Floating versions mean a transitive upgrade can break production silently, often weeks after the change.

Is there a README or basic setup guide that lets a second developer run the project?

If onboarding engineer number two requires the founder to walk them through setup, that is a team-scaling bottleneck.

Are there obvious signs of copy-paste code or duplicated logic across the codebase?

Copy-paste programming at pre-seed is common. It becomes a maintenance crisis once the team starts growing.

Are there any hardcoded API keys, tokens, or passwords anywhere in the repository or its git history?

Even if removed from HEAD, credentials in git history are permanently compromised and must be rotated immediately.

Are .env files or configuration files with real credentials accidentally committed to version control?

A surprisingly common mistake. The liability is immediate and permanent until credentials are rotated.

Is user input validated before being processed by the application?

Input validation prevents the most common and most avoidable class of critical vulnerabilities: injection attacks.

Are third-party dependencies checked against known vulnerability databases (CVEs)?

Vulnerable npm, pip, or gem packages are among the most common vectors for breaches at early-stage companies.

Is the data model reasonably structured and indexed for the primary read/write patterns?

A badly designed schema at pre-seed almost never gets redesigned until it causes outages in production.

Are there obvious N+1 query patterns or synchronous blocking operations on the critical user path?

These patterns work at 100 users and silently cause outages at 10,000.

Is the application deployed in a way that would allow scaling beyond a single server?

Single-server deployments are acceptable at pre-seed. What matters is that scaling does not require rewriting the application.

Is there any automated test coverage, even a minimal smoke test for the core user journey?

No tests at pre-seed is common and acceptable. The absence of even one smoke test suggests testing is not part of the culture.

Does the application handle errors gracefully, or do unhandled exceptions expose stack traces to end users?

Stack traces in user-facing responses are both a security signal and a reliability one.

Is the deployment process repeatable, or is it a manual procedure known only to the founding engineer?

Single points of deployment knowledge are a team risk, not just a technical one.

Is there any logging in place that would allow the team to diagnose what happened after a production incident?

Without logs, debugging production issues is archaeology. Early-stage teams waste significant time on this.