Internal Tool Pre-Launch Checklist: 20 Things to Verify Before Going Live

Shipping an internal tool to your team feels lower-stakes than shipping a customer-facing product. It is not. A broken customer feature affects users you can monitor. A broken internal tool affects the people who run your operations, handle customer escalations, and process your revenue — and the failure often happens quietly.

Run through this checklist before anyone on your team relies on the tool in a production context.

Internal Tool Pre-Launch Checklist

Access Control

• Roles and permissions are defined and documented. Every user type has a named role. Every role has an explicit set of permitted actions. Nothing is granted by default.
• Access control is enforced server-side. Hiding UI elements from unauthorized users is not access control. Every API endpoint that writes data validates the caller's permissions before executing.
• Admin-level access is restricted to a named list of individuals. Not "anyone on the engineering team." Named individuals, reviewed before launch.
• New user accounts require explicit role assignment. A new user who signs up or is invited should have the most restrictive role by default, not admin.

Data Safety

• Destructive actions require explicit confirmation. Bulk deletes, status changes affecting many records, and any irreversible action prompt the user to type a confirmation or click a clearly labeled "I understand this is permanent" confirmation.
• Writes go through your service layer, not directly to the production database. Direct database access from admin UIs bypasses your application's validation and business logic.
• Bulk operations have rate limits or caps. A form that lets a support agent update 500 records at once with no throttle is a liability.
• Soft deletes are implemented for any records a user might want to recover. Hard deletes without a recovery path should be reserved for cases where data retention is intentionally prohibited.

Audit and Observability

• Every write operation is logged with actor, action, resource, and timestamp. This is non-negotiable for any tool that modifies production data.
• Application errors are routed to your error tracking system. Not just logged — actively surfaced so someone sees them.
• Slow queries and API calls are instrumented. If the tool becomes slow, you want to know which operations are responsible.
• There is a defined owner for this tool's uptime and bug reports. One named person or team who receives reports and is responsible for response.

Performance

• Data tables paginate server-side. Any table that could contain more than a few hundred rows should fetch pages, not all rows.
• Queries run against a read replica where appropriate. Admin queries that aggregate or scan large datasets should not compete with production traffic.
• The tool loads in under three seconds on a standard internal network connection. Test this with realistic data volumes, not development seed data.
• Filtering and search operations use indexed database columns. A search that triggers a full table scan will cause problems at scale.

Operational Readiness

• At least two people know how to deploy an update. Not just the engineer who built it — at minimum one other person can push a fix if the primary is unavailable.
• There is a rollback procedure for bad deployments. If a bad deploy breaks the tool on a Friday afternoon, what is the recovery path?
• Internal documentation covers the main workflows. Not a novel — a short reference that answers "how do I do X?" for the five most common operations.
• The tool has been tested end-to-end by at least one actual user who was not involved in building it. Builders have blind spots. Someone who was not in the room for every design decision will find them.

A Note on "Good Enough"

Not every item on this list needs to be a polished production implementation before the tool goes live. An audit log that writes to a simple database table is good enough. Error tracking that sends emails to a shared inbox is good enough. Server-side pagination that does not have perfect UX is good enough.

What is not acceptable: shipping a write-enabled tool with no access control, no audit log, and no error visibility. Those three things are the minimum viable safety layer for any internal tool that touches production data.

The rest of the list is about reliability and maintainability — things that matter, but can be iterated on after the initial launch if the team is aware of the gaps.

Ship with the safety layer complete. Iterate on everything else.

Clixo builds and ships internal tools with the right foundations from day one.