shipshape / review
Free working checklist

10 checks before a small web app release

A short, evidence-based pass for a solo founder or small team. Record what you checked, what happened, and who owns any remaining action. A checked box is not proof of security by itself.

Use safely: run checks in a test or staging environment wherever possible. Don’t paste secrets into tickets or email. For production data, use approved access and a documented change window.
01

Can another person reproduce the build?

Start from a clean clone and follow the documented setup. Note missing steps, unpinned dependencies, and undocumented environment variables. Keep actual secret values out of documentation.

Record: commit, command, result, and setup gaps.
02

Are the key user journeys verified?

Walk through sign-up or sign-in, the core action, an expected failure, and sign-out on the supported browser and viewport sizes.

Record: test account, steps, expected result, actual result.
03

Does the server enforce access control?

With two test accounts, create a record as B and try to request it as A. Also try the relevant update or delete path. A hidden button is not an authorization check.

Record: endpoint or route, test identities, status, and whether data was returned.
04

Do invalid inputs fail safely?

Try empty, malformed, too-long, and out-of-range values on important forms and API requests. Confirm validation happens on the server for security-sensitive actions.

Record: input case, expected response, actual response.
05

Did you review dependency findings?

Run the package manager’s audit or alert workflow, identify affected production dependencies, and choose a tested update or a documented mitigation. A clean scanner result is not a complete security assessment.

Record: tool and date, relevant findings, decisions, owner.
06

Are production errors visible without leaking data?

Trigger a safe test failure. Confirm the team can find it and that logs do not expose passwords, tokens, session cookies, or unnecessary personal information.

Record: where the event appears, who sees it, and what sensitive fields were checked.
07

Can you restore important data?

If the app stores important data, confirm backups exist and follow a restore procedure in a safe environment. A successful backup job alone does not prove recoverability.

Record: backup date, restore test, duration, and gaps.
08

Is the release change reversible?

Write down how to roll back the deployment and what happens to database changes or queued work. Avoid assuming that reverting application code reverses data migrations.

Record: rollback owner, steps, dependencies, and last rehearsal.
09

Are configuration and access scoped?

Check required production configuration by name, confirm test credentials are not production credentials, and remove stale deploy keys or broad access that is no longer needed.

Record: configuration presence without values, access owner, removals needed.
10

Is someone watching after deployment?

After release, confirm the expected version is live, exercise one safe smoke check, and name who receives reports and decides whether to roll back.

Record: version or commit, smoke-check result, monitor, decision owner.

This checklist is educational guidance, not a penetration test, certification, legal opinion, or guarantee. Adapt it to the app’s risks. For identity and authorization tests, use synthetic data and accounts you control.

Ask a checklist question →Read the two-account access-control walkthrough