Internal tools

The starting point is almost always a spreadsheet that has become load-bearing — a pipeline, a roster, a reconciliation, a queue — kept by one person, edited by several, and correct only as long as everyone follows a convention nobody wrote down.

Authentication exists from the first commit instead of being added before launch. A tool that starts on an unguarded address because it is only internal for now is a tool that will still be unguarded in two years, holding considerably more sensitive data than it did on the day that decision was made.

Permissions are modeled on roles that already exist in the business rather than invented for the software. Where the business genuinely has one kind of user, the tool has one role, and adding a second later is a small change; inventing five roles nobody asked for produces a permission matrix that is maintained by guesswork.

Every destructive action is recoverable or confirmed. Records are marked as removed rather than deleted where history matters, and anything genuinely irreversible states plainly what it is about to do.

An audit trail records who changed what and when. In a tool that holds operational truth, the question that eventually gets asked is not what the value is but when it changed and who changed it, and a system that cannot answer that converts a two-minute question into an afternoon.

Interfaces are built for the person doing the task repeatedly instead of for a first-time visitor. Dense is correct here. Keyboard operation, sensible defaults, and the next action already in focus matter more than an onboarding flow nobody will see twice.

Export is built in from the start. A tool the business cannot get its data out of is a tool the business does not really own, and the export path is also the most reliable disaster recovery available for a system small enough not to warrant more.