Production readiness checklist for indie hackers and solo founders

The checklist you skip when you're rushing to ship

There's a version of "production ready" that means "it works on my machine and I ran it past two beta users." Most indie hackers live here, and honestly, for a week-one soft launch, that's fine. The problems start when real traffic arrives: a spike from a Hacker News post, a mention in a newsletter, someone putting your app in a "tools I actually use" thread. That's when the things you skipped turn into outages.

This is not an exhaustive ops rundown. It's the things solo founders most commonly miss, in rough order of how badly they bite.

---

Secrets and environment variables

Start here because the blast radius of getting this wrong is immediate and permanent.

Run this before you do anything else:

# Check for secrets accidentally committed to git history
git log --all --full-history -- "*.env" "*.pem" "*.key"
git grep -i "api_key\|secret\|password\|token" -- "*.js" "*.ts" "*.py" "*.env"

If either command returns output you weren't expecting, rotate every credential in those results. Not "probably rotate." Rotate.

Beyond secrets in git, check that you're not constructing API calls with hardcoded values "just for now." That variable from six sprints ago is still there. Do a search for your actual provider names and key prefixes (like sk-, AIza, ghp_) in source files.

---

Error handling and observability

I genuinely don't know how many solo founders ship with no error tracking at all. More than admit it. The symptom is that you find out about bugs from users on Twitter, not from an alert.

At minimum you need:

• An error tracking service with email alerts for new issue types. Sentry has a free tier.
• Application logs you can actually read after the fact. If your app crashes and restarts, you want to know what happened. Structured JSON logs going somewhere persistent (Logtail, Axiom, Grafana Cloud) beat console.log to a dying container.

For the alerting side: set up one alert on error rate, not just error count. A sudden jump from 0% to 5% error rate matters. A count of 10 errors might not, depending on your traffic.

---

Rate limiting and abuse protection

Your signup endpoint will be hit by bots within hours of launch. Your API will get scraped. Add rate limiting before you launch, not after.

The pattern most frameworks support looks roughly like this:

// Express example with express-rate-limit
import rateLimit from 'express-rate-limit'

const signupLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 5,
  message: { error: 'Too many signup attempts, try again later.' }
})

app.post('/auth/signup', signupLimiter, signupHandler)

Apply stricter limits to auth endpoints (signup, login, password reset) than to read endpoints. A legitimate user does not attempt to log in 200 times in a minute.

---

Dependency hygiene

Your node_modules folder is a pile of code you didn't write and haven't read. Some of it has known vulnerabilities.

npm audit
# or
pnpm audit

Run this now. High-severity findings in direct dependencies need fixing before launch. High-severity findings in transitive dependencies (packages of packages) are worth understanding: is that code path actually reachable from your app?

Also check: when did you last update your dependencies? If the answer is "when I created the project," that's probably six months ago and things have moved.

---

Graceful shutdown and health checks

Containers get killed. Processes get restarted. If your app drops in-flight requests when that happens, you're creating intermittent errors that are hard to reproduce and annoying to debug.

Add a health check endpoint if you don't have one:

app.get('/health', (req, res) => {
  res.json({ status: 'ok', uptime: process.uptime() })
})

Then add a SIGTERM handler so your process drains existing connections before exiting:

process.on('SIGTERM', () => {
  server.close(() => {
    process.exit(0)
  })
})

Docker, Kubernetes, and most PaaS providers use SIGTERM. Without a handler, you're dropping connections on every deploy.

---

Backup and data loss

This one is short because the answer is boring: does your database back up automatically, and have you ever restored from that backup?

If you can't answer yes to both, you don't have a backup. You have a backup file you've never verified.

Most managed database services (PlanetScale, Supabase, Neon, Railway) do automatic backups. Check the retention period and where restores happen in their dashboard before you need them.

---

What to skip for now

You don't need a full incident runbook. You don't need distributed tracing. You don't need a multi-region setup. Those matter at scale, not at launch.

What you need is: no secrets in git, some error visibility, rate limiting on auth, current dependencies, and a working health check. That's the difference between an app that survives its first traffic spike and one that doesn't.

Get those right, then launch.

---

Seaworthy is a static analysis tool that scans a repository and flags issues across security, ops, resilience, dependency hygiene, configuration, and data exposure categories, via npx seaworthycode or as a VS Code extension.