Internal tools often fail for simple reasons: they are designed in a meeting instead of beside the work, they try to do everything, and nobody owns them after launch. These four steps keep the scope to one job, put real users in the loop from the first week, and plan ownership before anything is built.

Step 1 — Watch the job

Goal: Understand the work before designing anything.

  1. Sit with the people who do the job and watch a few real runs.
  2. Note every system, spreadsheet and copy-paste step involved.
  3. Write down the one outcome the tool must make faster or more reliable.
  4. Check whether existing tools can be configured to do it first.

You finish with: A short job description and the single outcome to improve.

Step 2 — Design the smallest version

Goal: Cut the scope to what the job needs.

  1. Sketch the screens or steps on paper with the users.
  2. Keep only what is needed for the main job; list everything else for later.
  3. Decide which systems it reads from and writes to, with the narrowest access.
  4. Agree who owns it after launch and how changes are requested.

You finish with: A one-page scope with an owner and a later list.

Step 3 — Build and test with users

Goal: Put a working version in front of real users early.

  1. Build the main flow first and share it within the first weeks.
  2. Have users run real work through it alongside the old way.
  3. Fix what slows them down before adding features.
  4. Write short instructions inside the tool itself.

You finish with: A working tool tested on real work.

Step 4 — Launch and maintain

Goal: Make it part of the routine and keep it working.

  1. Switch over once users prefer the tool to the old way.
  2. Monitor errors and usage, and set up alerts for failures.
  3. Review the later list each month with the owner.
  4. Keep code, hosting and accounts in the company’s name.

You finish with: A launched tool with an owner, monitoring and a change process.

Common pitfalls

  • Designing in a meeting instead of beside the work.
  • Building every requested feature before launch.
  • No owner after the builder moves on.
  • Skipping monitoring until something silently breaks.

More guides like this

Related answers

Read as Markdown Build the missing piece