Custom software ownership and handover checklist

When construction software becomes part of the working day, ownership needs to be practical. Your business should know what it receives, who keeps the application running and how another team could maintain it. Agree those details before development starts.

What does owning custom software include?

Separate the rights to the custom work from access to the services that run it. The proposal and agreement should identify the code, designs, documentation and data delivered to you, the rights to use and change them, and when the handover takes place.

Ask which parts use existing libraries, licensed components or external services. A custom application can still depend on paid hosting, maps, messaging or other software. Owning the application does not make those services free. Use the construction software cost guide to record them alongside the build price.

Keep an account and access register

For each service, record the business owner, administrator, billing contact and recovery contact. Decide whether the account belongs to your company or is provided through an agreed managed service.

• Source code: the repository, release history and instructions for building the application.
• Hosting and database: where the live application and records run, plus any separate testing environment.
• Domain and sign-in: who manages the address, company login and user access.
• Connected systems: integration accounts, permitted actions and renewal requirements.
• Operational tools: backups, monitoring, error alerts, storage and messaging.

Store credentials securely; the register should point to their location rather than contain passwords. Verify that the nominated people can use their accounts. A developer saying that access is available is different from your administrator successfully signing in.

Ask for a usable handover

The receiving technical team needs enough information to understand, release and recover the application. The handover should include:

• A map of the application, its data and its external dependencies.
• Setup instructions, supported software versions and configuration requirements.
• The release procedure and a way to return to the previous working version.
• Data definitions, export instructions and backup and restore procedures.
• Known limitations, unfinished work and the agreed support contact.

Use the provider’s supported transfer process where ownership of an account or repository changes. For example, GitHub documents what moves with a repository, including associated collaborators and configuration. Review access after the transfer instead of assuming it has been removed.

Prove that the handover works

Before sign-off, ask the receiving team to complete four checks in a safe test environment: start the application from the instructions, release a small change, export representative records and restore a backup. Include attachments and relationships between records in the export check.

For a construction business, useful records might include the approved submission, its project, evidence and review history. A spreadsheet containing only the latest totals may leave behind information the office still needs.

Record the result and resolve missing steps. AWS recommends testing recovery and checking the restored data; a successful backup notification alone does not demonstrate that the application can be recovered.

Decide who looks after it after launch

You can own software while paying someone to operate it. Choose an internal technical owner, ongoing support from the builder, or another qualified provider. Whichever route you choose, name the people responsible for:

• Hosting bills, renewals and service availability.
• Security updates, access changes and backup checks.
• Failed integrations and changes made by other software vendors.
• User questions, defects and new feature requests.

Agree support hours, how an urgent issue is reported and what the response commitment covers. Separate fixing an agreed defect from developing a new feature. If support ends, specify the assistance and access needed to move to a new provider.

A short checklist to take into a proposal review

1. Can we identify exactly what we own or are licensed to use?
2. Do we have the agreed access to code, data and accounts?
3. Can the receiving team run, change, export and restore the system?
4. Are recurring charges and operating responsibilities clear?
5. Is there a practical route to change support providers?

D25 Works defines ownership, hosting, handover and support when scoping custom construction software. Add these decisions to your requirements checklist, alongside the workflow the application needs to support.