Key takeaways
- Name the assets, the threats, and the owner before you buy another security tool.
- Secrets do not belong in the repo, the screenshot, or the support ticket.
- Recovery is a rehearsal. A backup nobody has restored is a wish.
You shipped the prototype on a weekend. The API key lived in a GitHub gist. The founder's password was `admin123` on staging. A customer asked about GDPR and you realised you had never listed what you store.
Secure by design is not a SOC 2 badge on the pricing page. It is the habit of naming what you protect, how it fails, and who fixes it before the first incident email. Small product security fails quietly — a leaked key, a dependency with a known CVE, a restore that nobody has tested. The checklist is smaller than enterprise theatre. It still has to run.
What to do after you launch covers measurement and care. This page stays on the product boundary: data you hold, keys you rotate, and the recovery path when something goes wrong.
Name assets, threats, and owners
A minimum threat model fits on one page. You do not need STRIDE posters. You need answers a new engineer can read in ten minutes.
Assets — what hurts if it leaks or disappears:
- Customer accounts and profile data
- Payment tokens (you should not store raw card numbers)
- Business data your app processes on behalf of clients
- Admin credentials and integration keys
- Availability of the service itself
Threats — how those assets fail in a small team reality:
- Credential stuffing and reused passwords
- Secrets committed to git or pasted in Slack
- Unpatched dependencies with public exploits
- Over-broad API keys in the browser
- A deleted database with no tested restore
Owners — one name per class, even if that name is the founder tonight:
- Who rotates keys?
- Who approves dependency updates?
- Who can access production data?
- Who runs the restore drill?
OWASP Application Security Verification Standard is a useful reference ladder. You will not implement every control on day one. You will know which gaps you accepted on purpose.
Dependency and secret handling
Small teams treat npm install as free. It is not. Every dependency is code you did not write and will not read — until it ships a vulnerability bulletin.
Dependencies:
- Pin versions in lockfiles. Run `npm audit` or your platform equivalent on a schedule, not only at launch.
- Remove packages you do not use. Dead dependencies still scan in audits.
- Subscribe to security advisories for your framework — Next.js, Django, Rails, whatever you chose.
Secrets:
- Environment variables in deployment, not in the repository. GitHub documents secret scanning because commits leak constantly.
- Separate keys per environment. Staging keys are not production keys with a prefix.
- Rotate after any person leaves, any laptop is lost, any screenshot might have shown a token.
- Never log secrets. Redact authorization headers in error reports.
If your app prototype embeds a third-party API key in client-side JavaScript, assume it is public. Design for scoped, rate-limited keys and server-side proxies for anything sensitive.
Authentication and access without enterprise cosplay
You do not need a bespoke auth system. You do need defaults that do not embarrass you:
- Passwords hashed with a modern algorithm — bcrypt, Argon2, or your framework's recommended default.
- Multi-factor on admin and billing accounts.
- Session expiry that matches risk — shorter for admin, reasonable for customers.
- Role separation: support should not mean database root.
OWASP Authentication Cheat Sheet is the plain-language reference. Read the session management section before you ship "remember me forever."
For a small B2B app, the expensive mistake is giving every customer user admin rights because it was faster in the demo.
The recovery test
Backups that nobody has restored are folklore. Run the recovery test quarterly:
1. Create a meaningless record in production — or use a staging mirror with production-like size. 2. Trigger your backup snapshot. Note the timestamp. 3. Restore to an isolated environment. Measure time to usable. 4. Log in. Confirm the record, integrations, and background jobs behave. 5. Document gaps — missing secrets, wrong DNS, manual steps nobody remembered.
If restore takes longer than your acceptable downtime, fix the process before you need it. Google Cloud's backup and DR guidance applies at any scale: define RTO and RPO in words a founder understands, not only in infrastructure slides.
Include dependency on third parties in the test. If auth is outsourced, if email is outsourced, if files live in object storage — the drill must touch those paths.
Privacy and retention are security cousins
Security asks who can access data. Privacy asks why you hold it and for how long. A small product still needs:
- A plain list of data categories you collect
- Retention defaults — delete stale trials, anonymise old logs
- A path for access and deletion requests where regulation applies
You do not need a fifty-page policy on day one. You need honesty in the product: do not collect fields you will never use. Technical SEO checklist 2026 and analytics choices intersect here — tracking pixels are data processing too.
What ships in a secure prototype
An app prototype should leave with:
- Threat model one-pager
- Secrets in environment config, not git
- Dependency audit in CI or a monthly calendar invite
- Recovery test notes from at least one drill
- Admin MFA enabled
A full website with forms and accounts needs the same discipline at the edge — TLS, form spam controls, hosted secrets for email and CRM hooks.
App development and web development at CLICK.BLUE include these defaults because incidents are cheaper to prevent than to explain. Twelve-plus years, fifty-plus businesses, a hundred-plus websites — most never made the news. That is the point.
You can run the asset list and recovery drill yourself this week. Wiring auth, key rotation, and production hardening without breaking the release train is where a scoped build earns its place.
Start with what you actually store. Secure by design is the operating habit, not the badge.
