A pre-release checklist for a healthtech startup, step by step

Before a healthtech release goes to production, confirm that the change was reviewed by someone else, required checks passed, dependencies were scanned, no new sensitive logging or third-party calls were added, a rollback path exists and the evidence is saved. Ten items, written down, make this repeatable for a small team.

Why a checklist, not a process manual

Small teams ship often. A heavy approval process gets bypassed. A short checklist enforced by the pipeline survives. The aim is to move as many items as possible from memory into automated checks, and leave a few for human judgment.

The ten items

1. A pull request exists with a linked ticket.
2. At least one reviewer other than the author approved it.
3. Required status checks passed: build, tests, dependency scan.
4. No new dependency was added without an intake form.
5. No new log fields contain identifiers, free text or secrets.
6. No new third-party script or SDK was added without a data flow review.
7. Database migrations are reversible, or a recovery plan exists.
8. Feature flags default to off for risky changes.
9. A rollback step is written and was tried in staging.
10. The release record is saved: version, approver, date, checks.

What the platform can enforce

GitHub documents several branch protection options that map directly onto items 2 and 3: required approving reviews, required status checks that must succeed before merge, CODEOWNERS review, a block on force pushes and a requirement that changes deploy successfully to specific environments first. It also says the rules do not apply to admins by default unless you choose the option that stops bypass. For a healthtech team, turn that option on, or restrict bypass to a named break glass path.

Human judgment items

Items 5, 6 and 7 usually need a person. Give the reviewer a short prompt in the pull request template: does this change what we log, who we send data to, or the shape of stored data?

Evidence after release

Keep the pull request, review approvals, check results and the deploy record. If your pipeline writes them to a standard place, evidence collection becomes a by-product of shipping. One folder or one report per release is enough.

Rolling back

A rollback you have never practiced is a hope, not a plan. Rehearse it in staging for each release type: application only, application plus migration, and configuration change. Note the time it took.

Try it yourself

Click through it at your own pace, or open it full screen.

Watch a gate stop a change that does not meet a policy, then see what a passing change looks like.

Where Safeguard fits

Safeguard provides policies, gates and guardrails, dependency scanning and compliance and evidence automation, which map to items 3, 4 and 10. The rest stays with your team and your judgment. A free scan is available at gold.safeguard.sh/scan.

Quick check

Sources

• GitHub Docs: About protected branches

Last reviewed: 19 October 2026.