A tool built around
your work, not someone
else’s compromises.

I do not start with a list of screens: first I understand who uses the tool, what decisions they make and what should happen after a record is saved or rejected.

When a custom internal tool makes sense

Off-the-shelf software is often the right choice. A custom internal application becomes reasonable when the team repeatedly works around its limits, copies data between spreadsheets or needs rules, roles and history that a generic product cannot express.

That can mean an approval workflow, internal records, planning, operational checks or work that depends on several sources. The goal is not to create another system. It is to remove a specific source of friction and keep a clear record of who changed what.

The first version needs a boundary

The main risk is usually not a lack of ideas but a scope that is too wide. When every future request enters version one, the team never gets to test the basic value.

I start with one workflow that has a clear beginning and outcome. The first version may include a focused interface, basic roles, change history and one important integration. If the team uses it and the value is clear, later features are added with better knowledge of reality.

What should be designed from the start

• Roles and permissions: each person sees and changes what they need.
• History: changes and their timing remain traceable.
• States: a record moves through known steps instead of disappearing into “done”.
• Exceptions: users know what to do when data is missing or a connected service fails.
• Handover: the tool does not depend on one person remembering how it works.

Web or desktop?

A web application works well when several people need shared data and access from different devices. A desktop tool may fit local work, a specific device or a controlled environment where response time matters.

I do not choose based on a favourite framework. I consider deployment, data sensitivity, number of users, API dependencies and who will operate the solution.

How the tool is built

1. Work situations: current workflow, roles, inputs, outputs and exceptions.
2. First-version boundary: what we verify now and what we deliberately leave out.
3. Working increment: a usable part, not only a set of screens.
4. Operations and handover: tests, configuration, documentation and common recovery steps.

What improves after adoption

A well-scoped internal tool standardises a workflow, reduces dependence on personal memory and gives the team a history of decisions. Users do not have to guess which spreadsheet should contain a value, and managers do not have to reconstruct the current state from several manual reports.

If the real problem is an undecided process, I recommend clarifying that first. Software cannot replace a decision the business has not made yet.