When should you build an internal tool?

Look at what the business already pays for. A change to configuration, permissions or the way information is captured may solve the problem with less maintenance.

Check whether people understand and use the current process. New software will not resolve an ownership problem on its own.

Write down what users cannot do today. They may need to review work from several systems, approve an exception or hand over a complete record without retyping it.

Describe the required behaviour rather than starting with a long list of screens. The first version should solve a defined problem for named users.

A tool can meet a technical specification and still make the day harder. Ask users to walk through a recent task and test a representative version before launch.

Their input helps identify awkward permissions, missing fields and extra checking work that a diagram may miss.

Your agreement should explain source-code and licence rights, account access, documentation and responsibility for maintenance.

Someone needs to manage changes in connected systems, investigate faults and decide whether new requirements belong in a later scope.

If the business cannot support that ownership, an established product may be a better option.

Choose one workflow and agree what successful completion looks like. Define the inputs, user actions, permissions and failure behaviour.

Avoid building a replacement for every spreadsheet at once. Learn whether the first tool is used and whether the measured benefit justifies further work.