Internal tools / Build-or-buy worksheet
Internal tools modernization: move beyond fragile spreadsheets
Capture the decisions hidden inside the spreadsheet.
Download worksheetEditable CSV · Open in your spreadsheet app
Download article in MarkdownAn internal-tool project should remove a specific operational burden. Start with the spreadsheet, inbox, or shared document that staff rely on to complete a repeated task. Understand what works before deciding whether the replacement should be an existing application, a low-code tool, or custom software.
Find the process hidden inside the spreadsheet
Ask an experienced user to complete the task while explaining each decision. Capture the meanings of colors, abbreviations, copied formulas, protected cells, and comments. These often encode rules that were never written down elsewhere.
Watch someone less experienced attempt the same task. Where do they ask for help? Which cells can they safely change? How do they know a request is complete? Those questions reveal the interface and training requirements of a replacement.
Microsoft's app-planning material starts with the business problem, users, and goals. The worksheet below adds an operating boundary: who maintains the tool and what happens when it is unavailable.
Separate calculation from permission
A spreadsheet may calculate a proposed purchasing quantity and also serve as an informal approval record. Treat those as separate responsibilities. The person who prepares a request may not be authorized to commit the purchase.
Define the roles and the actions each role can perform. Include viewing sensitive fields, changing a request, approving it, exporting data, and administering access. Approval should refer to the exact version under review. If the amount or supplier changes, decide whether the approval must be renewed.
Compare build, buy, and improve
| Question | Evidence to gather | What it changes |
|---|---|---|
| What task repeats? | Steps, volume, waiting time, and exceptions | The smallest useful scope |
| Is an existing tool close enough? | Demonstration using difficult real scenarios | Buy versus configure versus build |
| Which data is authoritative? | Field owners and update direction | Integration and validation design |
| Who can act? | Roles, approval rules, and access review owner | Permissions and audit requirements |
| Who will maintain it? | Named owner, support route, and change budget | Ongoing cost and feasibility |
| Can the team exit? | Export format, documentation, and account ownership | Vendor dependence and handover |
Pilot one job with the people who perform it
Consider an illustrative supplier-onboarding process. Requests arrive by email, a spreadsheet tracks missing documents, and a finance manager approves the supplier. A first release could provide a request form, a status queue, and an approval record. It does not need to become a complete procurement platform.
Test incomplete submissions, duplicate suppliers, rejected documents, changed bank details, and an approver who is unavailable. Financial changes need the business's established verification controls; an attractive form should not weaken them.
Let operators use the pilot with representative work before expanding it. Keep a clear procedure for exceptions and agree whether the existing tracker remains authoritative during the trial. Running two editable systems without a reconciliation rule can create more work than it removes.
Count waiting time as well as typing time
A tool can reduce data entry while leaving the approval queue unchanged. Measure the time a request spends waiting, the number of corrections, completion time, and repeated entry of the same information. Track adoption by the intended users and the reasons they return to the old process.
Separate released staff capacity from cash savings. Saving an hour of repetitive work may let someone handle more useful tasks; it does not automatically reduce payroll. The TCO and ROI guide explains how to keep those benefits distinct.
Before handover, confirm ownership of the application, accounts, data, documentation, and support queue. An internal tool becomes part of daily operations as soon as people depend on it. Include that responsibility in the first proposal.
Your next step
Discuss your modernization
Share the task, your current systems, and the decision you need to make. We’ll discuss a useful first scope.
Discuss your modernization