Indie developers need a security checklist too

When I worked at a company, many security measures were almost invisible.

Company email, device management, permission approvals, code review, production environments, user data — someone set the rules for all of it. Once you build products on your own, that layer of protection suddenly disappears.

The domain, code, database, APIs, payments and user information are all concentrated in your own hands. You’re not just the product manager, designer and developer; you also become your own IT, security and incident response team.

And the most common security problem for an indie product usually isn’t some sophisticated attack; it’s a basic mistake that gets amplified fast.

1. Treat an API key as a permission, not a string of characters

API keys, database passwords, cloud service credentials, payment secrets: at heart, each one is an authorization.

Whoever gets it may be able to call services as you, run up charges, read data, or even modify or delete resources.

So I now stick to a few baselines:

• don’t put secret values in code, AI chats, screenshots, issues, logs or documents;
• don’t put server-side secrets in the browser or a mobile app;
• use .env for local development, and add it to .gitignore before committing code;
• in production, use the secret management your deployment platform provides;
• use different credentials for development, testing and production;
• wherever permissions, quotas and scopes can be limited, limit them.

.env isn’t a safe either. It just keeps secrets from being written directly into code. If the file gets uploaded, shared or recorded in a log, it can still leak.

There’s another very important principle:

If a secret has already been committed to Git, deleting the file later isn’t enough. It may still live in the Git history.

The first thing to do then isn’t to “cover your tracks,” but to revoke or rotate it immediately and get a new credential.

2. Protect the few accounts that really control your product

For an indie product, the most important accounts aren’t necessarily the product’s admin panel, but:

• your main email;
• GitHub;
• your domain registrar;
• cloud services and deployment platforms;
• the database;
• payment accounts.

Lose any one of them and you could lose control of the whole product.

These accounts should at least have different passwords and MFA turned on, with recovery codes stored safely.

Especially your main email. Many accounts can reset their passwords through email, so it’s really the master entry point to all your permissions.

3. Don’t just ask “can I upload this file?”

Uploading to a third-party service doesn’t necessarily mean the file is public on the internet.

But it does mean the information has left an environment you fully control.

These days I’d rather ask:

• Where will the file go?
• Who might access it?
• How long will it be kept?
• Can it be deleted?
• Do I really need to upload the full original?
• Could I do this with anonymized data, test data or a local tool?

When developing on your own, be especially careful with production databases, user data, admin screenshots and real logs.

To get AI to help debug, pasting a whole production dataset, full logs or user information into a chat is usually not the only option.

Often, keeping just the structure of the error, the field names and a minimal reproduction is enough.

4. Work out the worst case for an AI agent’s permissions too

AI agents can read code, run commands, edit files, access GitHub, and even connect to email, cloud drives and databases.

That makes one person building a product much more efficient, and it also means one wrong action can go much further.

Before granting access, I consider:

• Does it really need the whole repo, or just one directory?
• Does it need write access, or is read-only enough?
• Does it need access to production?
• Do actions like deleting, deploying, sending and paying need human confirmation?
• When I stop using it, will I revoke its access?

The point isn’t to assume the tool will definitely make mistakes, but to make sure that even if it does, one mistake doesn’t take everything with it.

5. Don’t just prevent incidents; prepare to recover

No system can guarantee nothing will ever go wrong.

So security also includes:

• whether there are database backups;
• whether those backups can actually be restored;
• whether alerts for unusual logins, charges and API calls are on;
• whether APIs have quotas or rate limits;
• whether you know where to revoke a key if it leaks;
• whether you can quickly roll back a bad deployment;
• whether you know which users would need to be notified.

Really practical security isn’t about chasing zero risk; it’s about containing the impact of any single incident.

An indie product security self-check

I check at least these 12 things:

• MFA is on for main email, GitHub, domain, cloud services and payment accounts
• No passwords are reused across important accounts
• Recovery codes are stored offline
• No secret values in code, chats, screenshots or logs
• .env and other sensitive files are in .gitignore
• Confirmed that sensitive files never entered the Git history
• Production secrets are stored in the deployment platform’s secret management
• Development, testing and production credentials are separate
• No server-side secrets in the front-end bundle
• Third-party tools and agents only get the permissions they need
• Spending or anomaly alerts are set for APIs, cloud services and payment platforms
• Data is backed up, and the restore process has been tested at least once

Building a product on your own means you get to decide many things yourself.

But the flip side of that freedom is that nobody will automatically check these boundaries for you.

Security may not be the most exciting part of a product.

But once something goes wrong, it may suddenly become the most important part.