An internal tool launch checklist for the first real team

The first team launch is a change in responsibility. A prototype that was safe to experiment with alone becomes something other people use to make decisions. The right checklist makes those responsibilities visible without pretending that every small tool needs an enterprise programme.

Use this as a discussion and evidence list. Mark each item verified, not yet verified, not applicable with a reason, or blocked. A tick without a person, date and supporting observation is difficult to rely on. This checklist is not an exhaustive security assessment or a certification.

1. Define the release boundary

Name the workflow being released, the first users and the actions they may take. Describe what is deliberately excluded. A read-only reporting pilot is a different release from allowing users to edit source records or trigger customer communications.

Write a short success condition. For example: “Three operations colleagues can review requests and record decisions without giving one another administrator access.” This is more useful than “the app is ready”. It ties the release to work people can actually perform and verify.

Identify a reversible pilot. Limit the audience, use appropriate data, document a fallback and choose a review date. Do not use the word “pilot” to excuse exposure of sensitive information or irreversible actions. The limits need to exist in the application and operating process.

2. Verify identity and permissions separately

Confirm how accounts are invited, authenticated, disabled and recovered. Decide who can create another administrator. Check what happens to an active session when access is removed, rather than assuming a changed account flag immediately stops every request.

Test each important role through the server interfaces, not only the visible buttons. Try an unrelated record identifier, a direct export request and a write operation. If workspaces or organisations exist, test two of them with deliberately different records.

A successful sign-in proves an identity check succeeded. It does not prove that the application applied the correct authorization to every action. Our access and permissions guide explains how to build a small test matrix for these boundaries.

3. Know the data you hold

List the categories of personal, confidential and operational data the tool stores or sends to other services. Include logs, analytics, uploads and background jobs. Avoid using a production database as casual test material.

Decide which fields are necessary, how corrections work, who can export data and when records should be removed. If AI services receive inputs, include those transfers in the inventory. “The model needs context” is not a sufficient explanation for sending every available field.

Use separate credentials and data for development and production. Check that secrets are not embedded in browser bundles or committed to source history. Rotating an exposed secret matters more than merely deleting its current file.

4. Check the important failure paths

Try invalid input, a repeated submission, a slow dependency and a failed external request. Determine whether retrying is safe. A request that times out may already have succeeded at the provider, so an automatic repeat can duplicate an email, booking or financial action.

Show an honest user state when the outcome is uncertain. Preserve enough information for reconciliation. For background work, verify that restarting a worker does not forget accepted work or perform internal actions twice.

Focus testing on consequences. A missing decorative animation and a duplicated invoice do not deserve equal release priority. Make known limitations explicit so the pilot users understand what to report and what not to rely on.

5. Make deployment repeatable

Keep the source, dependency lockfile and environment requirements under version control. Build and deploy through a repeatable process with a recorded version. Avoid a release that depends on changing files manually on a server.

Test the deployed application’s health and one representative workflow. A process that starts successfully can still be unable to reach its database. Check the public URL, TLS, redirects and the data connection actually used in production.

Define rollback before deployment. Rolling back application code is not automatically safe after a database migration. Prefer compatible changes where possible, and record the conditions under which an earlier version can run. Never reverse data changes blindly because a rollout failed.

6. Demonstrate recovery

Back up the relevant database, files and configuration. Keep access to the recovery material separate enough that losing the production machine does not lose both copies. Protect that material: a backup often contains the same sensitive information as the live system.

Restore into a disposable environment and inspect the result. Record the recovery time and the latest data available. Compare them with what the business can tolerate. A recovery document that has never been exercised is an assumption, not evidence.

Name the person who can perform recovery when the original builder is unavailable. If only one person holds an essential key, write down how authorised recovery works. Do not put secrets in the public launch checklist itself.

7. Assign operation and communication

Decide who receives health alerts, how users report a problem and who can disable a failing integration. Agree on support hours and escalation. Tell pilot users when the tool is being maintained and where the fallback process lives.

Record supplier accounts, billing ownership and the domains involved. Set sensible spending and resource limits. Confirm that a service interruption or exhausted quota produces a manageable state instead of an endless retry loop.

The NIST Secure Software Development Framework describes practices for reducing software vulnerabilities across development. It is a useful reference for a deliberate process, not a claim that this short checklist covers the framework or proves compliance.

8. Make the go/no-go decision explicit

Review unresolved items with the person who owns the business risk. Separate release blockers, accepted limitations and later improvements. Record the reason and owner for each accepted limitation, with a date to revisit it.

Do not average away a serious issue because many minor checks passed. A tool with a polished interface, fast loading and good documentation can still be unsuitable to launch if one user can read another organisation’s confidential records.

After launch, review actual usage, incidents and support requests. Update the checklist based on what you learned. The point is not to complete a document once; it is to establish a repeatable way to change a tool that people now depend on.

If you want an outside view, tell us what you have built. A free fit call can establish whether a scoped review or launch project makes sense. Implementation, hosting and ongoing support are agreed separately.