SOFTWARE FACTO Software factory acceptance and handover worksheet Version 1.0 | Prepared 23 October 2026 Source and guidance: https://softwarefacto.com/journal/software-factory-buyer-checklist/ Use one copy for one important workflow. This is an editable discussion aid; agree the scope and terms of an engagement separately. Keep the completed copy in your own appropriate storage. Record where credentials are managed, never the credentials themselves. WORKFLOW Project or workflow: _______________________________________________ Person or team using it: ___________________________________________ Prepared by: ______________________ Date: ________________________ Decision owner: ____________________ Next review: _________________ STATUS KEY For each section, choose one status: E = evidenced against the agreed version P = agreed, but the check is still pending U = unresolved N = not applicable, with a reason recorded An evidence reference can be a test result, demonstrated output, repository revision, release record or written agreement. Record the version and date where relevant. A promise is not an observed test. Do not average these statuses into a score. Identify which unresolved items must be settled before the next commitment or release. 1. ESTABLISH WHETHER A BUILD IS JUSTIFIED Outcome: What must the named user be able to do? __________________________________________________________________ Current process and the problem to improve: __________________________________________________________________ Essential scope: __________________________________________________ Explicit exclusions: ______________________________________________ Existing product, configuration or process alternatives considered: __________________________________________________________________ Important gap that remains: ________________________________________ Evidence/reference: ________________________________________________ Status (E/P/U/N): ____ Reason or open question: ____________________ Owner: _______________________ Decision/check due: ________________ 2. AGREE WHAT PASSING MEANS Normal case - input, action and expected result: __________________________________________________________________ Difficult case - input, action and expected result: __________________________________________________________________ Failure case - what must stop, be rejected or be surfaced to a person? __________________________________________________________________ Who accepts the result? ____________________________________________ Version/revision to be checked: ____________________________________ Check performed and date: __________________________________________ Observed result: __________________________________________________ Known limitations or behaviours not checked: _______________________ Evidence/reference: ________________________________________________ Status (E/P/U/N): ____ Reason or open question: ____________________ Owner: _______________________ Decision/check due: ________________ 3. CLARIFY SOURCE, ACCOUNTS AND ACCESS For each dependency, record: Item | Owner | Access/rights | Recurring supplier | Handover/exit step __________________________________________________________________ __________________________________________________________________ __________________________________________________________________ Consider source code, configuration, third-party components/licences, hosting, domain, integrations, administrative access and data exports. Where operating instructions and access records will be kept: __________________________________________________________________ How credentials will be transferred and old access removed: __________________________________________________________________ What is needed to continue without the original supplier: __________________________________________________________________ Evidence/reference: ________________________________________________ Status (E/P/U/N): ____ Reason or open question: ____________________ Owner: _______________________ Decision/check due: ________________ 4. REHEARSE A CHANGE AND A RECOVERY Who approves a release? ____________________________________________ Checks required before release: ____________________________________ How the released revision will be identified: ______________________ How a failure will be detected, and who receives it: __________________________________________________________________ How service can be restored: _______________________________________ Backup/restore arrangements and last demonstrated check: __________________________________________________________________ Does reverting code also restore affected data? ____________________ If not, what repair path and decision owner are required? __________________________________________________________________ Recovery limitations or consequences that remain: __________________________________________________________________ How defects and new requirements will be distinguished: __________________________________________________________________ Evidence/reference: ________________________________________________ Status (E/P/U/N): ____ Reason or open question: ____________________ Owner: _______________________ Decision/check due: ________________ 5. PRICE THE OPERATING LIFE Build cost and agreed scope/reference: _____________________________ Recurring item | Payer | Estimate/range | Usage assumption or limit __________________________________________________________________ __________________________________________________________________ __________________________________________________________________ Consider hosting, storage, external APIs, model usage, licences, monitoring, maintenance, support and your own team's operating work. Who reviews rising costs, and when? ________________________________ Who handles support? _______________________________________________ Coverage and response expectations: ________________________________ What is included/excluded: _________________________________________ Escalation route: __________________________________________________ Who operates it if no supplier support is purchased? __________________________________________________________________ Evidence/reference: ________________________________________________ Status (E/P/U/N): ____ Reason or open question: ____________________ Owner: _______________________ Decision/check due: ________________ 6. MAKE THE NEXT DECISION Decision being made: _______________________________________________ Evidence supporting it: ____________________________________________ Unresolved item | Consequence | Owner | Due date | Blocks next step? __________________________________________________________________ __________________________________________________________________ __________________________________________________________________ Next action and its boundary: ______________________________________ Decision owner: _______________________ Date: _____________________ Next review or acceptance check: ___________________________________ Keep previous versions when the scope or evidence changes. Record what changed so a new person can understand why the work moved forward. Further context: https://softwarefacto.com/software-factory/ https://softwarefacto.com/build-or-buy/