Software fix checklist: 12 checks before a fix is handed over

The bug or feature is written down: steps to reproduce, what you expect, what you see, and the version or branch
Logs or a screenshot of what you see let the fix start from your bug, not a guess.
It is one fix or one small feature, not a redesign or a migration
Anything bigger is scoped and quoted on its own before any work on it starts.
Access is limited to the one repository: an invite to it, or a fork pull requests can be opened from
Nothing outside that repository needs to be shared.
The README or the commands to install the app and run its tests are written down
If the bug needs a test or staging environment, it holds test data only.
No production credentials are shared: tests use mocks or test-mode keys kept in your own CI or .env
No key is put into a model prompt or committed; a key found in the repository should be rotated.
No health or finance data is in the code path, unless a written scope covers it
Regulated data needs its own written scope and a decision before the work starts.
A named contact answers questions and confirms acceptance
Someone on your side has to say the fix is accepted.
A new test fails on your old code and passes with the change
The test proves the bug existed and is gone, and keeps it from coming back.
Your existing test suite still passes
Your CI is green, or the run is shown in the pull request.
The behaviour in the written scope works as the handover note describes
You check the result against what was agreed in writing.
Nothing changed outside the files the scope named, except tests
A small fix stays small and easy to review.
You merge the pull request yourself; nobody else merges to your main branch or deploys
Your code and your releases stay in your hands.

0 of 12 done

12 left to do:

The bug or feature is written down: steps to reproduce, what you expect, what you see, and the version or branch
It is one fix or one small feature, not a redesign or a migration
Access is limited to the one repository: an invite to it, or a fork pull requests can be opened from
The README or the commands to install the app and run its tests are written down
No production credentials are shared: tests use mocks or test-mode keys kept in your own CI or .env
No health or finance data is in the code path, unless a written scope covers it
A named contact answers questions and confirms acceptance
A new test fails on your old code and passes with the change
Your existing test suite still passes
The behaviour in the written scope works as the handover note describes
Nothing changed outside the files the scope named, except tests
You merge the pull request yourself; nobody else merges to your main branch or deploys

Want us to fix it with you?

Our fixed-scope software fix or small feature order delivers one fix or one small feature in one repository: a written scope, a failing test first, the smallest change that makes it pass, a separate review and a handover note.

Ask about a software fix See a sample fix report Our services

This checklist is not a code review or a security audit.

Is this fix ready to hand over?

0 of 12 done

Want us to fix it with you?